On Thu, 2024-01-11 at 14:36 -0800, Linus Torvalds wrote: > On Wed, 10 Jan 2024 at 12:48, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi- > > misc > > Ok, I note that this has been signed with ECDSA key > E76040DB76CA3D176708F9AAE742C94CEE98AC85, and while it is currently > available and up-to-date at kernel.org, it shows as > > sub nistp256 2018-01-23 [S] [expires: 2024-01-16] > E76040DB76CA3D176708F9AAE742C94CEE98AC85 > > note that expiration date: it's three days in the future. > > Can I please ask you for the umpteenth time to STOP DICKING AROUND > WITH SHORT EXPIRATION DATES! > > The pgp keyservers work *so* badly these days that refreshing keys is > a joke. The whole expiration date thing has always been a bad joke, > and only makes pgp an even worse UX than it already is (and damn, > that's saying a lot - pgp is some nasty stuff). Well, I did already tell you that I bypass the pgp keyservers because I use a DNSSEC based DANE entry instead: https://lore.kernel.org/all/1564171685.9950.14.camel@xxxxxxxxxxxxxxxxxxxxx/ And I'm sure there was an earlier one where you confirmed this worked, but lore seems to be missing it. > When you make a new key, or when you extend the expiration date, do > it properly. Give ita lifetime that is a big fraction of a decade. Or > two. > > Because your keys constantly end up being expired, and they are > making the experience of pulling from you a pain - because I actually > *check* the keys. > > Stop making a bad pgp experience even worse - for no reason and > absolutely zero upside. I can concede that if I'm the only person with a DANE updateable key then it is a pain to remember because gpg doesn't automatically do it (although it can be configured to), so I can certainly set a longer expiry date. James
