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

On Wed, 2026-02-04 at 11:49 +0100, Uwe Kleine-König wrote:
> On Tue, Jan 27, 2026 at 01:08:12PM -0800, Linus Torvalds wrote
[...]
> > 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.

That's not a good reason: we already have a set of key distribution
mechanisms now and have no need of additional percolation ...
particularly as our key uses are mostly limited to tag signing for one
person.

[...]
> 
> > 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.

OK, so come up with a good argument how short expiry would work for the
way kernel developers use keys.  You're the one asking for us to adopt
a currently non-standard practice, so the burden is on you to argue for
it. (and the percolation argument above isn't good enough because it's
irrelevant to our workflow).

[...]
> 
> 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.

That's just propaganda: gpg can absolutely manipulate the trust
database independently from the signatures on import.  I think I
explained this on the users list only the other day (how we could use
trustdb to compensate for all our 2011 issued sha1 key signatures in
the kernel keyring).  However, trustdb manipulations are hard for
casual users to understand and get right.

Regards,

James

-----BEGIN PGP SIGNATURE-----

iJEEABMIADkWIQTnYEDbdso9F2cI+arnQslM7pishQUCaYRtbhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDIACgkQ50LJTO6YrIUycgEA9B9Jj83Ou6ZYMI0dqcjm
C3s5c9zOqFgZaEQbO8q3q7MBAPpBebtXUr+3WaGI3ZnA2wG4a8vRNdRHLh0y4qfD
6y8D
=RbDX
-----END PGP SIGNATURE-----