Re: [GIT PULL] first round of SCSI updates for the 6.7+ merge window

[James Bottomley]

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