From: Konstantin Ryabitsev <mricon@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: "Greg KH" <gregkh@linuxfoundation.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
users@kernel.org, ksummit@lists.linux.dev
Subject: Re: Web of Trust work [Was: kernel.org tooling update]
Date: Fri, 23 Jan 2026 13:23:58 -0500 [thread overview]
Message-ID: <20260123-provocative-tungsten-curassow-cc2aac@lemur> (raw)
In-Reply-To: <8fde8057e2bacb1bd3bd2c15134a6f69ef037699.camel@HansenPartnership.com>
On Fri, Jan 23, 2026 at 12:23:09PM -0500, James Bottomley wrote:
> > > Could you please stop doing this? The Open Source norm is to
> > > release early and often and long before you have stable code so you
> > > get feedback incorporated *before* you're committed to something.
> >
> > I'm not doing anything here, sorry.
>
> You're listed as a presenter on the session Mauro pointed to. And
> you're the only kernel developer on it, so I was presuming you were
> helping them out with kernel requirements.
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.
- 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.
- 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.
- I said: sure, come up with some code and let's see, as long as the following
is assured:
- It's opt-in; anyone who is happy using GnuPG can continue without any
change
- We're not forcing a complete rekeying or resigning of all keys
- There is no central service that must be up and accessible for the tools
to work
- It's not written in some esoteric framework that requires curl | bash
every 2 weeks to get the latest version
- I also made it very clear that the kernel community will have the final say
in whether this is adopted or not.
This is pretty much where we stand.
-K
next prev parent reply other threads:[~2026-01-23 18:23 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 [this message]
2026-01-23 21:12 ` Uwe Kleine-König
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=20260123-provocative-tungsten-curassow-cc2aac@lemur \
--to=mricon@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=gregkh@linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=ukleinek@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