From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Uwe Kleine-König" <ukleinek@kernel.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Konstantin Ryabitsev <mricon@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 13:08:12 -0800 [thread overview]
Message-ID: <CAHk-=whoJY_pORG8M_K5kSA-x0+MwRa5wHwkHY4sbYbPFegc_g@mail.gmail.com> (raw)
In-Reply-To: <4ilnblmm3srkyzq7o5ehlr2gnlrrnmr67dpoqxiy5vbrrqlqd5@my3rxybcpu5t>
On Tue, 27 Jan 2026 at 00:39, Uwe Kleine-König <ukleinek@kernel.org> wrote:
>
> 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.
I have never ever seen any good reason for automatic expiration, and
it causes actual real problems because *NOBODY* ever renews those
expiration in time and makes sure that they actually percolate out.
We literally had that happen just last week, and that was with a
person that is supposed to be an *expert* in those things, and that
uses fancy DNS key distribution etc.
So no. No expiration dates. They are stupid and do not work in
practice. End of story.
They are ALSO stupid because they make old signatures *look*
untrusted. Just go and do
git log --show-signature @{15.years.ago}
and look for 'expired'. It's all just sad and pointless, . What
matters was whether that key was trusted AT THAT POINT IN TIME, not
whether it's trusted now. But that's not how things work.
And here is why they are completely pointless: a key that is no longer
trusted should be *REVOKED*.
And no, I'm not talking about the (bad) support that PGP itself has,
which requires a revocation key that nobody ever actually has.
Sure, if you have a revocation key, by all means use it, but I doubt
it has ever been used in any form in reality except for testing.
So when I say "revoke it", I'm talking about just letting people know
that a key is no longer trustworthy, and then they should remove it
from their keychain.
(And no, you shouldn't randomly and automatically add keys from people
just because of some "I can reach it with a web of trust", so your
keychain shouldn't be in a situation where some old untrusted key
randomly then gets added back)
Because once the key is no longer trustworthy, some "it will expire in
two years" is COMPLETE AND UTTER GARBAGE.
WTF? You'd have to be completely insane to think that is an acceptable
or sensible in *ANY* form. It's too stupid for words, I don't
understand how anybody can even entertain that kind of complete
bullshit.
So stop with the idiotic key expiration garbage. It's completely
unacceptable because it doesn't work in practice, and IT IS INCREDIBLY
STUPID TO BEGIN WITH.
In practice, the only thing it results in is that when people lose
their private keys, they eventually expire, but why should anybody
care about that? If the key is lost, it's become *more* secure, for
chrissake.
Any web of trust that actively encourages idiocy is not a web of trust
I want to have anything to do with.
Yes, this is a pet peeve of mine. PGP is UX a disaster to begin with,
the key distribution sucks, and expiry dates just make everything
worse.
Linus
next prev parent reply other threads:[~2026-01-27 21:08 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 [this message]
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='CAHk-=whoJY_pORG8M_K5kSA-x0+MwRa5wHwkHY4sbYbPFegc_g@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=James.Bottomley@hansenpartnership.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