ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <ukleinek@kernel.org>
To: Konstantin Ryabitsev <mricon@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	users@kernel.org, ksummit@lists.linux.dev
Subject: Re: Web of Trust work [Was: kernel.org tooling update]
Date: Fri, 23 Jan 2026 22:12:39 +0100	[thread overview]
Message-ID: <c4aa6604-e076-4f04-85a6-d0267a3fb8e8@kernel.org> (raw)
In-Reply-To: <20260123-provocative-tungsten-curassow-cc2aac@lemur>


[-- Attachment #1.1: Type: text/plain, Size: 2806 bytes --]

Hello Konstantin,

On 1/23/26 19:23, Konstantin Ryabitsev wrote:
> They are primarily working with me, and just so it's clear -- this is not
> any kind of assured thing. Here's where things stand:
> 
> - they asked us how we currently do our trust framework and I described the
>   process and its drawbacks, which are real:
> 
>   - 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?

>   - We can't reasonably expand this to all kernel developers (not just
>     maintainers), because of constant churn of people coming, going, taking
>     breaks, etc. Maintaining the web of trust consisting of thousands of keys,
>     as opposed to hundreds, would become a full-time job if we stick to how
>     it's currently done (via the git repo and manual verification on my part
>     for all key additions).
>   - We're limited to PGP only, but it would be nice to also support something
>     like fido2 ssh key signatures.

I personally am happy with PGP and I don't see the benefit of using ssh
keys instead. But I'm open to look at the approach that we will see in
February.

> - they said they could come up with something that would use self-sovereign
>   did's that would allow scaling the trust framework to all kernel developers
>   and be self-sustaining and verifiable via cross-signatures.

123456789012345678901234567890123456789012345678901234567890123456789012

(Maybe apart from self-sustaining) this sounds like PGP. I consider it
self-sovereign as it's only me who has control over my certificate and
cross-signatures work fine, too. I agree that using GnuPG isn't nice for
newcomers and people only using it occasionally. But it is able to do
all the things we need from it, it has integration in git and mail (and
also ssh if you want) and I'd hesitate to throw that all over board for
something shiny new. I wonder if a new tool that covers all the needed
use-cases can be considerably simpler than PGP. And if that new tool
allows to let me continue using my PGP certificate, the complexity
cannot be less than PGP alone.

Having said that, I'd like to support you in the maintenance of the
pgpkeyring if this is considered helpful.

Best regards
Uwe

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

  reply	other threads:[~2026-01-23 21:12 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-10  4:48 kernel.org tooling update Konstantin Ryabitsev
2025-12-10  8:11 ` Mauro Carvalho Chehab
2025-12-10 13:30 ` Thorsten Leemhuis
2025-12-11  3:04   ` Theodore Tso
2025-12-12 23:48   ` Stephen Hemminger
2025-12-12 23:54     ` Randy Dunlap
2025-12-16 16:21 ` Lukas Wunner
2025-12-16 20:33   ` Jeff Johnson
2025-12-17  0:47     ` Mario Limonciello
2025-12-18 13:37       ` Jani Nikula
2025-12-18 14:09         ` Mario Limonciello
2026-01-23  9:19 ` Web of Trust work [Was: kernel.org tooling update] Uwe Kleine-König
2026-01-23  9:29   ` Greg KH
2026-01-23 11:47     ` Mauro Carvalho Chehab
2026-01-23 11:58       ` Greg KH
2026-01-23 12:24         ` Mauro Carvalho Chehab
2026-01-23 12:29           ` Greg KH
2026-01-23 13:57         ` Konstantin Ryabitsev
2026-01-23 16:24     ` James Bottomley
2026-01-23 16:33       ` Greg KH
2026-01-23 16:42         ` Joe Perches
2026-01-23 17:00           ` Steven Rostedt
2026-01-23 17:23         ` James Bottomley
2026-01-23 18:23           ` Konstantin Ryabitsev
2026-01-23 21:12             ` Uwe Kleine-König [this message]
2026-01-26 16:23               ` Konstantin Ryabitsev
2026-01-26 17:32                 ` Uwe Kleine-König
2026-01-26 21:01                   ` Konstantin Ryabitsev
2026-01-26 23:23                   ` James Bottomley
2026-01-27  8:39                     ` Uwe Kleine-König
2026-01-27 21:08                       ` Linus Torvalds
2026-02-04 10:49                         ` Uwe Kleine-König
2026-02-05 10:14                           ` James Bottomley
2026-02-05 18:07                             ` Uwe Kleine-König
2026-02-05 18:23                               ` Konstantin Ryabitsev
2026-01-26 23:33                   ` Mauro Carvalho Chehab
2026-01-26 23:06                 ` Mauro Carvalho Chehab
2026-01-23 21:38             ` James Bottomley
2026-01-23 22:55             ` Mauro Carvalho Chehab
2026-01-23 16:38       ` Konstantin Ryabitsev
2026-01-23 17:02         ` Paul Moore
2026-01-23 18:42 ` kernel.org tooling update Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4aa6604-e076-4f04-85a6-d0267a3fb8e8@kernel.org \
    --to=ukleinek@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=mricon@kernel.org \
    --cc=users@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox