Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113918
Return-Path: <php@golemon.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 80660 invoked from network); 1 Apr 2021 16:26:25 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
by pb1.pair.com with SMTP; 1 Apr 2021 16:26:25 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
by php-smtp4.php.net (Postfix) with ESMTP id 4674B1804D0
for <internals@lists.php.net>; Thu, 1 Apr 2021 09:24:13 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: *
X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,
HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_SOFTFAIL autolearn=no
autolearn_force=no version=3.4.2
X-Spam-Virus: No
X-Envelope-From: <php@golemon.com>
Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by php-smtp4.php.net (Postfix) with ESMTPS
for <internals@lists.php.net>; Thu, 1 Apr 2021 09:24:12 -0700 (PDT)
Received: by mail-lf1-f50.google.com with SMTP id i26so3692299lfl.1
for <internals@lists.php.net>; Thu, 01 Apr 2021 09:24:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=jGsHRBEDZAqQh6B2SfMis8EU5fgGQTL89Z25tUkKPA0=;
b=CKYl7CYEuijhOfme5YYJqAGOA26wgDBrEXBDAcuU4Xa8wCREzIcUyGG055S7Gbt7LT
fikBsMr4JrEgBlLAfSHVxkdVQU6mq8Xdgt9COZhFCE9RKBITScwx/BWhQ6I/75VY+t6V
wSwjC7nemTfqAIGkc1yuepOnssx01NsPg3bwE2Iotu3t3xCZvniKsPDzQ80N1nQWJq2j
YPVE5vZnY2GG+qT4DGM7EXF6jScVIbIT6IF3AdMVLldketCMO7WwoXMxz1OoJ+twcqS6
jQkSJxpJtJPxL841J/1ppEuZlCMjOYglJQGb+sciWwoGaCzr0woNWJSmcE3qj4Jvxf6h
uzew==
X-Gm-Message-State: AOAM532VXwzv+4YzDoPtKokvFAV9xjO+nViUkgbEtgag+AWTS7FskfqS
UWXKlJdwfrdFUN0kDFWxROnKLIOD/wQvJ5vcGl2N6naiBLCovpyq
X-Google-Smtp-Source: ABdhPJwrqFBaCHljYY3NmIiHHks/KONSylM/eha8kdJnpioCcVqIt5oiq6WYqDI+2tgWjFONweUp2jmHiQ9a2RfpiMQ=
X-Received: by 2002:ac2:5052:: with SMTP id a18mr5740128lfm.55.1617294250430;
Thu, 01 Apr 2021 09:24:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAF+90c9A6zG-nYzc3NNtWGjN7y5FmwqnYzjq6GSFC5NtRsOT0w@mail.gmail.com>
<CAN2symg2SueEONzMRndsWEhj6anXmeAQwKg+HzKh-o61bcP0Qg@mail.gmail.com>
<CAESVnVoPEitSCzmrAR2pRY4zUp4WEBc3a1b3q4H_uh1q8ebVWw@mail.gmail.com>
<CAEYWF=71sahVwiaPEAYMCfLd+fgZ5FA24bS-LCtzxNW==9H=xg@mail.gmail.com>
<c0849f5f-4233-d0f1-d00d-29840459070b@gmail.com> <CAEYWF=5PE9MKt_zxU8u+Mv0oHz_Stw3_vVNe1BWfO-5mZ7ab5g@mail.gmail.com>
<CAESVnVoeXy0NkbD+g4GOp-n2gUQ3G-rkfW-oaTAy4khUgMSUdw@mail.gmail.com> <a874febc-af61-cb2d-c16c-3f78daae25c1@gmail.com>
In-Reply-To: <a874febc-af61-cb2d-c16c-3f78daae25c1@gmail.com>
Date: Thu, 1 Apr 2021 11:23:59 -0500
Message-ID: <CAESVnVoS68LuXbVMHLm=KrJdJJ2va-WMRxLWWXUW-GrS5joVOg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004b68cb05beeba947"
Subject: Re: [PHP-DEV] Changes to Git commit workflow
From: pollita@php.net (Sara Golemon)
--0000000000004b68cb05beeba947
Content-Type: text/plain; charset="UTF-8"
On Thu, Apr 1, 2021 at 11:19 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:
> On 01/04/2021 15:59, Sara Golemon wrote:
> > On Thu, Apr 1, 2021 at 9:21 AM Bishop Bettini <bishop@php.net
> > <mailto:bishop@php.net>> wrote:
> >
> > I also added a FAQ.
> >
> >
> > I disagree with the position this document takes on immortal keys. We
> > should encourage best-practices with the knowledge that some people
> > will weaken their security with an immortal key, not start from a weak
> > position and suggest that adhering to best practices is "paranoid".
>
>
> I've been looking around, and most of what I can find says that expiring
> a primary key which you use directly for signing has very little value,
> because anyone who has the private key and passphrase can change the
> expiry date at any time. See for example:
> https://security.stackexchange.com/q/14718/51961
>
> The main use case seems to be when using sub-keys, where the primary key
> (with no expiry) is kept offline, and new sub-keys are generated from it
> regularly (e.g. once a year) with an appropriate expiry date.
>
> This is based only on a few hours of searching online, however, so I'd
> be happy to see a better explanation of how to use expiry effectively.
>
>
Yeah, I just got told the same offline. That's.... depressing. Not
surprising when one thinks about it more, but still depressing.
-Sara
--0000000000004b68cb05beeba947--