ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <ukleinek@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Konstantin Ryabitsev <mricon@kernel.org>,
	 Greg KH <gregkh@linuxfoundation.org>,
	users@kernel.org, ksummit@lists.linux.dev,
	 Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Web of Trust work [Was: kernel.org tooling update]
Date: Tue, 27 Jan 2026 09:39:17 +0100	[thread overview]
Message-ID: <4ilnblmm3srkyzq7o5ehlr2gnlrrnmr67dpoqxiy5vbrrqlqd5@my3rxybcpu5t> (raw)
In-Reply-To: <2ef60fa3afe287cec92020b8b77a37c0b70cefaa.camel@HansenPartnership.com>

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

Hello James,

On Mon, Jan 26, 2026 at 06:23:08PM -0500, James Bottomley wrote:
> On Mon, 2026-01-26 at 18:32 +0100, Uwe Kleine-König wrote:
> > Actually I'd like to see you/us add still more burden and asking
> > developers to only hand in keys with an expiry date <= (say) 3 years.
> > Something similar to what
> > https://www.gentoo.org/glep/glep-0063.html#bare-minimum-requirements
> > requests.
> 
> You have seen Linus' views on gpg key expiry, right?
> 
> https://lore.kernel.org/linux-scsi/CAHk-=wi03SZ4Yn9FRRsxnMv1ED5Qw25Bk9-+ofZVMYEDarHtHQ@mail.gmail.com/

Thanks for the link. I was aware that Linus isn't a big fan of PGP and
GnuPG. Still I think that having an expiration for your PGP certificates
is a very sensible thing. All at least halfway sensible howtos about PGP
handling that I saw in the past strongly recommend to set an expiry
date. (e.g.

	https://riseup.net/en/security/message-security/openpgp/gpg-best-practices#use-an-expiration-date-less-than-two-years

which isn't up to date in every corner any more, but the section about
expiry is still accurate.
According to https://book.sequoia-pgp.org/sq_key_generation.html, the
certificates generated using sq default to a 3 year expiry.)

Yes, I agree it's inconvenient, but updating is a usual necessity for
secure systems. SSL certificates have an expiry; letsencrypt will soon
limit expiries to 45 days. We regularly preach that people should update
their kernel and roll our eyes about hardware running Linux 5.15.153
(that's my DOCSIS router) or 2.6.26.8 (that's my wifi radio).

Security is a moving target; and if you don't move with it, your
security level drops over time.

Looking at the thread you referenced above, I think Linus would have
been happy if he had your updated key in time. So I only see this as a
challenge to improve the keyring maintenance.

> As a result of that I've taken to using much longer expiry periods.

:-(

Best regards
Uwe

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

  reply	other threads:[~2026-01-27  8:39 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 [this message]
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=4ilnblmm3srkyzq7o5ehlr2gnlrrnmr67dpoqxiy5vbrrqlqd5@my3rxybcpu5t \
    --to=ukleinek@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=mricon@kernel.org \
    --cc=torvalds@linux-foundation.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