ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <maurochehab@gmail.com>
To: Konstantin Ryabitsev <mricon@kernel.org>
Cc: "Uwe Kleine-König" <ukleinek@kernel.org>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	users@kernel.org, ksummit@lists.linux.dev
Subject: Re: Web of Trust work [Was: kernel.org tooling update]
Date: Tue, 27 Jan 2026 00:06:24 +0100	[thread overview]
Message-ID: <20260127000624.48c1af49@foz.lan> (raw)
In-Reply-To: <20260126-sophisticated-beluga-of-hurricane-00e16b@lemur>

Hi Konstantin,

On Mon, 26 Jan 2026 11:23:43 -0500
Konstantin Ryabitsev <mricon@kernel.org> 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.
> 
> > 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.  
> 
> Supporting ssh keys (along with minisign keys) is a Frequently Requested
> Feature (TM) -- not so much among kernel users, but among several other
> projects that use non-forge workflows.

Replacing PGP with ssh keys to push stuff at kernel.org is
welcomed, together with any mechanism to ensure the web of trust
for ssh keys, but see, the Web of Trust PGP keys are also used when we
sign git tags before asking Linus to merge:

	https://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git/tag/?h=media/v6.19-3

And also when we sign tags at the userspace tools we maintain. Any
alternative Web of Trust mechanism shall keep us allowing to sign
git tags with the same trust level.

At least up to git version 2.52.0, PGP is the only allowed
mechanism to sign tags.

Regards,
Mauro

  parent reply	other threads:[~2026-01-26 23:06 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
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 [this message]
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=20260127000624.48c1af49@foz.lan \
    --to=maurochehab@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=mricon@kernel.org \
    --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