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

Uwe Kleine-König <[email protected]> Mon, 26 Jan 2026 18:32:22 +0100
Newsgroups dev.linux.lists.ksummit
Message-ID <x5nnix4t2w74flef4xnivzw43gx7wdk7v3cirawq52qfd6qdty@he74b5uk26zc>
Hello Konstantin,

On Mon, Jan 26, 2026 at 11:23:43AM -0500, Konstantin Ryabitsev wrote:
> On Fri, Jan 23, 2026 at 10:12:39PM +0100, Uwe Kleine-König wrote:
> > >   - I am the bottleneck in the process, because all updates have to go through
> > >     me; even if we add more people to have access, this would still be a
> > >     bottleneck, because the more keys there are in the web of trust, the more
> > >     finagling the whole process requires to deal with expirations, key
> > >     updates, identity updates, etc. We can rely on modern keyservers for some
> > >     of it, but not for third-party signatures, which are key for our
> > >     distributed trust.
> > 
> > Just to ensure we're talking about the same thing: This is about calling
> > a script once a week or so, check the resulting diff, commit and push,
> > right?
> 
> This is for updates, yes, and this is mostly hands-off except final review.
> Adding new keys is usually a lot more involved, because there's frequently a
> back-and-forth required (they sent a key without any signatures, there is not
> enough signatures, the signatures are too far removed from Linus, etc). We
> currently have about 600 keys in the keyring we maintain, and we clearly can
> do a much better job like being more proactive when someone's expiry date is
> approaching. I'm worried that if we tried to maintain a keyring for several
> thousand people as opposed to several hundred, this would snowball into an
> unmaintainable mess.

Actually I'd like to see you/us add still more burden and asking
developers to only hand in keys with an expiry date <= (say) 3 years.
Something similar to what
https://www.gentoo.org/glep/glep-0063.html#bare-minimum-requirements
requests.

I suspect that among the 600 keys we have now, a considerable amount is
actually unused and it would be good for security to drop these. With an
expiry date detecting such keys would be much simpler.

I wonder why you expect the number of keys to rise considerably?!

> > Having said that, I'd like to support you in the maintenance of the
> > pgpkeyring if this is considered helpful.
> 
> I do appreciate your work!

Areas that I see where I could be helpful are:

 - moderating the keys ML
 - giving feedback to patches
   (currently I mostly see the patches when they are already handled
   because you seem to do moderation and patch handling in batches.)

Best regards
Uwe
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAml3pSMACgkQj4D7WH0S
/k4J4Af/c3z/Bj5FPXu3AyW+36zYNJ82PDJ/tdmKSVfOWWDkKfl1df7NfDbk2TYp
72x7Km6PITw8++bo8yLC5o4xXikc3J7Tep8rdjQ3ts5BRgu6sUhTLU7Nfd21Qc8E
lnDCxE8HoTK21klszcMn18Q3KiGgkuIxZWYdlVsPBIw6PQVkDV24GQWNUum8TXUK
RYe3s1/i3BbfmhWpr29ea2SorqhM0PjvBGlGBiStU6VoPWYQ+JnLo6I3TpCpVo5x
OZqy+106B687dARei6x49imi7x6658aZ5jUQEx3F+KQ4b/d8kwNomoDJyRzXx6AU
6x/jESg8X+u6TdBXkMYaLQn4bH1Lyg==
=pDGQ
-----END PGP SIGNATURE-----