From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.dasr.de (mail.dasr.de [202.61.250.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7F95426D14 for ; Wed, 4 Feb 2026 16:17:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.61.250.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770221873; cv=none; b=SjHc2CsFD5Jo+AeJfiApuCkxm0jfO+QWQ4yGcjzn+iRJ1FIRupsVUkvMVkvs7gIWJf6eefFp7a670HrgYU/s2cbwlpcKgMFOopO548GhAKznYyu6JkDSariXZN8PW1QEFHBMAtzlZH4f9EOJN4Cz3KEPfgEv4EdB8ZQjc9/eKIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770221873; c=relaxed/simple; bh=fClPz8lnvJrqcYkNqbc6W15OGjNdlxvxPvNYQDa+Lo0=; h=Date:Message-ID:From:To:Cc:In-Reply-To:References:MIME-Version: Content-Type:Subject; b=qrxDmN73nKHf4da0r3cfty+Tvo6PxJogr5hYqekAXrLO35IBkhRdY/s08z+Fwi61Cl5z2gXKArcHOzHY5yQ/VaWmfu8rAK60/6PmYR6TgfavmbG70FMKKp6ibx+CxMoWga3j6lKdZZRQuJ7oh60q+luckPGAolgJEE9Syga0SjY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=walfield.org; spf=pass smtp.mailfrom=walfield.org; arc=none smtp.client-ip=202.61.250.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=walfield.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=walfield.org Date: Wed, 04 Feb 2026 16:35:23 +0100 Message-ID: <87fr7g1pz8.wl-neal@walfield.org> From: "Neal H. Walfield" To: Uwe =?ISO-8859-1?Q?Kleine-K=F6nig?= Cc: git@vger.kernel.org, Linus Torvalds In-Reply-To: <20260204152306.1767112-2-ukleinek@kernel.org> References: <20260204152306.1767112-2-ukleinek@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.20.191 X-SA-Exim-Mail-From: neal@walfield.org X-Spam-Level: Subject: Re: [PATCH v1] gpg-interface: Signatures by expired keys are fine X-SA-Exim-Version: 4.2.1 (built Wed, 06 Jul 2022 17:57:39 +0000) X-SA-Exim-Scanned: Yes (on forster.huenfield.org) Hi, I think this change is an improvement over the status quo. In my opinion, a signature should be accepted if it was made when the certificate sas not expired. If the signature was made after the certificate expired it should be rejected. That is: t_s1: signature 1 t_e: certificate expires t_s2: signature 2 where: t_s1 < t_e < t_s2 signature 1 should be accepted as t_s1 < t_e. signature 2 should be rejected as t_s2 > t_e. As GnuPG's interface does not provide enough information to make this distinction, this change is better. :) Neal On Wed, 04 Feb 2026 16:23:06 +0100, Uwe Kleine-K=F6nig wrote: >=20 > If a signature is done with a valid key and that key later expires, the > signature should still be considered good. >=20 > GnuPG exmits in this case something like: >=20 > [GNUPG:] NEWSIG > gpg: Signature made Wed 26 Nov 2014 05:56:50 AM CET > gpg: using RSA key FE3958F9067BC667 > [GNUPG:] KEYEXPIRED 1478449622 > [GNUPG:] KEY_CONSIDERED D783920D6D4F0C06AA4C25F3FE3958F9067BC667 0 > [GNUPG:] KEYEXPIRED 1478449622 > [GNUPG:] SIG_ID 8tAN3Fx6XB2NAoH5U8neoguQ9MI 2014-11-26 1416977810 > [GNUPG:] EXPKEYSIG FE3958F9067BC667 Jason Cooper > gpg: Good signature from "Jason Cooper " [expired] > [GNUPG:] VALIDSIG D783920D6D4F0C06AA4C25F3FE3958F9067BC667 2014-11-26 14= 16977810 0 4 0 1 2 00 D783920D6D4F0C06AA4C25F3FE3958F9067BC667 > gpg: Note: This key has expired! > D783920D6D4F0C06AA4C25F3FE3958F9067BC667 >=20 > (signature and signed data in this example is taken from Linux commit > 756f80cee766574ae282baa97fdcf9cc). So GnuPG is relaxed and the fact that > the key is expired is only worth a "Note" which is weaker than e.g. >=20 > gpg: WARNING: The key's User ID is not certified with a trusted signatur= e! > gpg: There is no indication that the signature belongs to the o= wner. >=20 > which git still considers ok. >=20 > So stop coloring the signature by an expired key red and handle it like > any other good signature. >=20 > Signed-off-by: Uwe Kleine-K=F6nig > --- > Hello, >=20 > the motivation for this patch originates from a mail correspondence with = Linus Torvalds, > see > https://lore.kernel.org/ksummit/CAHC9VhRwMpSCphW_FsHojX1r12D5MOMUBm6MAzpG= YD_FDjEVtA@mail.gmail.com/T/#m6cc3cc4b599658cab6012326993a1261fd641046 > for the details. >=20 > Best regards > Uwe >=20 > gpg-interface.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/gpg-interface.c b/gpg-interface.c > index 47222bf31b6e..6635c6c8e16f 100644 > --- a/gpg-interface.c > +++ b/gpg-interface.c > @@ -382,7 +382,7 @@ static int verify_gpg_signed_buffer(struct signature_= check *sigc, > =20 > delete_tempfile(&temp); > =20 > - ret |=3D !strstr(gpg_stdout.buf, "\n[GNUPG:] GOODSIG "); > + ret |=3D !strstr(gpg_stdout.buf, "\n[GNUPG:] GOODSIG ") && !strstr(gpg_= stdout.buf, "\n[GNUPG:] EXPKEYSIG "); > sigc->output =3D strbuf_detach(&gpg_stderr, NULL); > sigc->gpg_status =3D strbuf_detach(&gpg_stdout, NULL); > =20 > @@ -680,7 +680,7 @@ int check_signature(struct signature_check *sigc, > if (status && !sigc->output) > return !!status; > =20 > - status |=3D sigc->result !=3D 'G'; > + status |=3D sigc->result !=3D 'G' && sigc->result !=3D 'Y'; > status |=3D sigc->trust_level < configured_min_trust_level; > =20 > return !!status; >=20 > base-commit: b2826b52eb7caff9f4ed6e85ec45e338bf02ad09 > --=20 > 2.47.3 >=20 >=20