Re: Web of Trust work [Was: kernel.org tooling update]

["Uwe Kleine-König" <ukleinek@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 6026 bytes --]

Hello Linus,

I had valuable input for writing this mail by Neal Walfield, so the
things expressed here are a combination of our thoughts.

On Tue, Jan 27, 2026 at 01:08:12PM -0800, Linus Torvalds wrote:
> On Tue, 27 Jan 2026 at 00:39, Uwe Kleine-König <ukleinek@kernel.org> wrote:
> >
> > Thanks for the link. I was aware that Linus isn't a big fan of PGP and
> > GnuPG. Still I think that having an expiration for your PGP certificates
> > is a very sensible thing.
>
> I have never ever seen any good reason for automatic expiration, and
> it causes actual real problems because *NOBODY* ever renews those
> expiration in time and makes sure that they actually percolate out.

A good reason is that it forces the users of your certificate to
participate in the percolation of your cert. This is relevant to make
updates to the key (new or revoked UIDs and subkeys) known. For that an
expiry time of 2 years is even quite long.

> We literally had that happen just last week, and that was with a
> person that is supposed to be an *expert* in those things, and that
> uses fancy DNS key distribution etc.

Of course this all breaks if the owner of the certificate doesn't work
on extending the expiry date in time. Partly this is a tooling problem.
The tools should warn users that their certificates are going to expire.
Neal already picked up that suggestion for Sequoia:
https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/622

Also for maintaining a keyring for a group of people (e.g. kernel
developers who have write access to kernel.org archives) an extension of
an expiry date is an easy indicator for the person still being active.
So an expiry date on the PGP certificate is a good dead man's switch for
people going slowly MIA because life gets in the way. Dropping access to
the project's infrastructure for people gone missing is a good security
measure.
I intend to keep an eye on the kernel pgpkeys repo and act as a reminder
for people that already have an expiry date on their key. I already
started (even before your mail) and it seems to work, e.g.
https://lore.kernel.org/keys/aYIQdlikYqHwps3I@do-x1carbon/T/#m5285386968f9c4b9cbeab3ebca83e39344ff2b29
https://lore.kernel.org/keys/hn4exg4aukkf6oc4gfe3v2dx6kzz5tgg52gtdcmlfeq3yqdode@z5xfwu5n4osc/T/#m6733201ded6f74b4a251d02f1330d71b26fff8be

> So no. No expiration dates. They are stupid and do not work in
> practice. End of story.

This is a poor argument. Such a failure doesn't necessarily mean that
the concept of expiry dates is wrong. I think in this case it's the user
holding the tool wrong (here: failure to add a reminder and act on it)
mostly because the tool makes it harder than necessary to be held
correctly (see above). In the same way a regression in Linux between say
6.17.4 and 6.17.5 shouldn't make people stop updating to later stable
kernels. Yes, this is annoying and the responsible key owners and stable
maintainers should work hard on preventing something like that
happening. But that doesn't mean expiry dates and stable updates are
wrong.

> They are ALSO stupid because they make old signatures *look*
> untrusted. Just go and do
>
>     git log --show-signature @{15.years.ago}
>
> and look for 'expired'. It's all just sad and pointless, . What
> matters was whether that key was trusted AT THAT POINT IN TIME, not
> whether it's trusted now. But that's not how things work.

This is also a tooling problem and I agree that a signature that was
created while the key was still fresh shouldn't appear in red here.

Looking at the signature stored in commit
756f80cee766574ae282baa97fdcf9cc which was made by a key that is expired
today and verifying it by hand with GnuPG gives:

	$ gpg --verify sig input
	gpg: Signature made Wed 26 Nov 2014 05:56:50 AM CET
	gpg:                using RSA key FE3958F9067BC667
	gpg: Good signature from "Jason Cooper <jason@lakedaemon.net>" [expired]
	gpg: Note: This key has expired!
	      D783920D6D4F0C06AA4C25F3FE3958F9067BC667
	$ echo $?
	0

(If you want to reproduce:
	git cat-file commit 756f80cee766574ae282baa97fdcf9cc | sed -n '/BEGIN PGP/,/END PGP/ { s/^ //p }' > sig
	git cat-file commit 756f80cee766574ae282baa97fdcf9cc | sed -n '/^mergetag/,/Remove/ { s/^mergetag //; s/^ //; p}' > input
)

There is no coloring involved and the output looks sane. So I think it
is git that is to blame here for making the output of

	git show --show-signature 756f80cee766574ae282baa97fdcf9cc

red? I'll bring that up on the git mailing list.

> And here is why they are completely pointless: a key that is no longer
> trusted should be *REVOKED*.

Agreed. And if Jason Cooper's key material was compromised and the
certificate revoked, red in git's output would be justified.

> So when I say "revoke it", I'm talking about just letting people know
> that a key is no longer trustworthy, and then they should remove it
> from their keychain.

Here is another weakness of how GnuPG handles things. In Sequoia, import
and trusting are two separate steps whereas when using a curated keyring
(which is what you seem to do with GnuPG), importing and trusting are a
single step. This means that users have to be very careful to not
inadvertently import a certificate they don't trust. The Sequoia model
allows you to import an untrusted key and only use a broken signature as
indicator for something being wrong but without having much trust in a
good signature.

> Because once the key is no longer trustworthy, some "it will expire in
> two years" is COMPLETE AND UTTER GARBAGE.

Agreed, trust and expiry correlate only very little.

All in all I hear your opinion (and wasn't terribly surprised by it :-)
and it contains a few valid points that need to be addressed. Thanks for
your input. Still I want to gradually push for getting more people in
the kernel pgpkeyring to use an expiry date for their crypto material
for the above stated reasons.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]