linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>, G@mit.edu
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	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: Sun, 21 Jan 2024 01:30:38 -0500	[thread overview]
Message-ID: <20240121063038.GA1452899@mit.edu> (raw)
In-Reply-To: <CAHk-=wi03SZ4Yn9FRRsxnMv1ED5Qw25Bk9-+ofZVMYEDarHtHQ@mail.gmail.com>

On Sat, Jan 20, 2024 at 11:35:18AM -0800, Linus Torvalds wrote:
> Guess why I don't? BECAUSE NOBODY ELSE DOES THAT POINTLESS EXPIRY DANCE.

So I guess I need to confess.  I haven't been doing the expiry dance
(which I started doing because GPG revocation certificates are also a
disaster).  There are certainly those folks who recommend it as a best
practice[1].

[1] https://www.g-loaded.eu/2010/11/01/change-expiration-date-gpg-key/

However, I tend to set the expiration 6 to 12 months in
advance, and make sure I renew them 3 months or so before they expire,
and then I make a point of sending them to keys@linux.kernel.org to
update the the kernel keyring, as documented here[2].

[2] https://korg.docs.kernel.org/pgpkeys.html

Linus, you haven't been complaining about my key, which hopefully
means that I'm not causing you headaches (or at least I hope so).
Would it be perhaps because you are periodically running
scripts/korg-refresh-keys as documented in [2].  Or perhaps you are
running it out of cron or a systemd timer (again, as documented in [2])?

Unlike James, I've tried to use DANE, since about the only thing that
has as disastrous a user experience as gpg is DNSSEC.  :-) I just
manually upload keys to the kernel and Debian keyrings, and it's been
working out, apparently without much pain for either me or to those
who rely on my keys --- at least, no one as complained to me so
far....

					- Ted

  parent reply	other threads:[~2024-01-21  6:30 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
2024-01-20 19:38       ` James Bottomley
2024-01-21  6:30       ` Theodore Ts'o [this message]
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=20240121063038.GA1452899@mit.edu \
    --to=tytso@mit.edu \
    --cc=G@mit.edu \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=torvalds@linux-foundation.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).