linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] final round of SCSI updates for the 6.7+ merge window
Date: Sat, 20 Jan 2024 11:35:18 -0800	[thread overview]
Message-ID: <CAHk-=wi03SZ4Yn9FRRsxnMv1ED5Qw25Bk9-+ofZVMYEDarHtHQ@mail.gmail.com> (raw)
In-Reply-To: <7b104abd42691c3e3720ca6667f5e52d75ab6a92.camel@HansenPartnership.com>

On Sat, 20 Jan 2024 at 11:09, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> It also seems that this magic option combination works better (just
> tried it on an old laptop that had my expired keys)
>
> gpg --auto-key-locate clear,dane --locate-external-key james.bottomley@hansenpartnership.com

So now I have a new subkey.

However, I note that you really do not seem to have gotten the message:

  sub   nistp256 2018-01-23 [S] [expires: 2026-01-16]
        E76040DB76CA3D176708F9AAE742C94CEE98AC85

WTF? What happened to "stop doing these idiotic short expirations"?

What's the advantage of all this stupid and pointless pain? Why didn't
you extend it by AT LEAST five years?

Has the expiration date *EVER* had a single good reason for it?

From a quick git lookup, in the last year I have pulled from 160
people. Imagine if they all set two-year expiration dates. Do the
math: I'd see pointlessly expired keys probably on average once or
twice a week.

Guess why I don't? BECAUSE NOBODY ELSE DOES THAT POINTLESS EXPIRY DANCE.

Why do you insist on being the problem?

Stop it. Really. I'm tired of the pointless extra work. PGP keys are a
disaster, and you keep on making things worse than they need to be.

               Linus

  reply	other threads:[~2024-01-20 19:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20 15:26 [GIT PULL] final round of SCSI updates for the 6.7+ merge window James Bottomley
2024-01-20 17:52 ` Linus Torvalds
2024-01-20 19:09   ` James Bottomley
2024-01-20 19:35     ` Linus Torvalds [this message]
2024-01-20 19:38       ` James Bottomley
2024-01-21  6:30       ` Theodore Ts'o
2024-01-21 15:58         ` James Bottomley
2024-01-21 18:48         ` Linus Torvalds
2024-01-24  5:36           ` Theodore Ts'o
2024-01-25 17:56             ` Linus Torvalds
2024-01-20 17:54 ` pr-tracker-bot

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-=wi03SZ4Yn9FRRsxnMv1ED5Qw25Bk9-+ofZVMYEDarHtHQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.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;
as well as URLs for NNTP newsgroup(s).