ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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

  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