ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Uwe Kleine-König" <ukleinek@kernel.org>,
	"Konstantin Ryabitsev" <konstantin@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 12:23:09 -0500	[thread overview]
Message-ID: <8fde8057e2bacb1bd3bd2c15134a6f69ef037699.camel@HansenPartnership.com> (raw)
In-Reply-To: <2026012340-wildlife-scratch-1efd@gregkh>

On Fri, 2026-01-23 at 17:33 +0100, Greg KH wrote:
> On Fri, Jan 23, 2026 at 11:24:33AM -0500, James Bottomley wrote:
> > On Fri, 2026-01-23 at 10:29 +0100, Greg KH wrote:
> > > On Fri, Jan 23, 2026 at 10:19:56AM +0100, Uwe Kleine-König wrote:
> > > > Hello Konstantin,
> > > > 
> > > > On 12/10/25 05:48, Konstantin Ryabitsev wrote:
> > > > > ## Web of Trust work
> > > > > 
> > > > > There is an ongoing work to replace our home-grown web of
> > > > > trust solution (that does work but has important bottlenecks
> > > > > and scaling limitations) with something both more distributed
> > > > > and easier to maintain. We're working with OpenSSF to design
> > > > > the framework and I hope to present it to the community in
> > > > > the next few months.
> > > > 
> > > > the current home-grown solution is
> > > > https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/, right?
> > > > 
> > > > I wonder what the bottlenecks and scaling limitations are that
> > > > you mention.
> > > > 
> > > > Is there some info available already now about the path you
> > > > (and OpenSSF) intend to propose?
> > > 
> > > There will be a presentation about this in February at a
> > > conference and hopefully it will be made public then as the work
> > > is still ongoing.
> > 
> > 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.  If that's not true then we
have even more cause to worry that people who don't understand how we
work are coming up with what they consider to be a "solution" without
any consultation.

> > You're making it very hard for those of us engaged in open source
> > advocacy inside various companies because we seem to spend a lot of
> > our time trying to get our engineers not to drop fully polished
> > projects into the public view but engage early on prototypes.  It
> > rather undermines our position if they can point to the Linux
> > Foundation and say "but they do it so why shouldn't we?".
> 
> When there is something that is reviewable, it will be released as a
> starting point for everyone to review and comment on, like any other
> normal open source project.  It's as if you don't think we know how
> any of this works...
> 
> Surely you don't want us to be touting a bunch of vaporware at this
> point in time, right?

There's a fairly reasonable separation between touting vapourware and
discussing requirements.  You're already causing requirements based
questions in the community, like worrying that we're ditching pgp that
Konstantin just answered.  A lot of us have a variety of solutions to
the web of trust problem.  I think you already know I use DNS based
distribution of my keys over DANE and am happy with it, but it's not
available to everyone  because you need to ground your email in a
DNSSEC backed domain to use it (and kernel.org still doesn't use
DNSSEC).  I'd be unhappy if DANE stopped working for the kernel web of
trust simply because no-one thought about it.

Regards,

James


  parent reply	other threads:[~2026-01-23 17: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 [this message]
2026-01-23 18:23           ` Konstantin Ryabitsev
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=8fde8057e2bacb1bd3bd2c15134a6f69ef037699.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=konstantin@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