Final round of fixes that came in too late to send in the first
request. It's 9 bug fixes and one version update (because of a bug
fix) and one set of PCI ID additions. There's one bug fix in the core
which is really a one liner (except that an additional sdev pointer was
added for convenience) and the rest are in drivers.
If you're still on a no power trip, these can also wait until -rc1.
As requested, I did a longer extension of my gpg keys, so my key needs
refreshing, before you pull, to fix the expiry date. You can get my
updates via DANE using:
gpg --auto-key-locate dane --recv D5606E73C8B46271BEAD9ADF814AE47C214854D6
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc
The short changelog is:
Bart Van Assche (2):
scsi: ufs: core: Remove the ufshcd_hba_exit() call from ufshcd_async_scan()
scsi: ufs: core: Simplify power management during async scan
ChanWoo Lee (1):
scsi: ufs: qcom: Remove unnecessary goto statement from ufs_qcom_config_esi()
Dan Carpenter (1):
scsi: fnic: unlock on error path in fnic_queuecommand()
David Strahan (1):
scsi: smartpqi: Add new controller PCI IDs
Dmitry Bogdanov (1):
scsi: target: core: Add TMF to tmr_list handling
Don Brace (1):
scsi: smartpqi: Bump driver version to 2.1.26-030
Harshit Mogalapalli (1):
scsi: fcoe: Fix unsigned comparison with zero in store_ctlr_mode()
Mahesh Rajashekhara (1):
scsi: smartpqi: Fix logical volume rescan race condition
Niklas Cassel (1):
scsi: core: Kick the requeue list after inserting when flushing
Randy Dunlap (1):
scsi: mpi3mr: Fix mpi3mr_fw.c kernel-doc warnings
And the diffstat
drivers/scsi/fcoe/fcoe_sysfs.c | 6 ++-
drivers/scsi/fnic/fnic_scsi.c | 1 +
drivers/scsi/mpi3mr/mpi3mr_fw.c | 6 +--
drivers/scsi/scsi_error.c | 9 ++--
drivers/scsi/smartpqi/smartpqi.h | 1 -
drivers/scsi/smartpqi/smartpqi_init.c | 89 ++++++++++++++++++++++++++++++----
drivers/target/target_core_device.c | 5 --
drivers/target/target_core_transport.c | 4 ++
drivers/ufs/core/ufshcd.c | 14 ++----
drivers/ufs/host/ufs-qcom.c | 7 +--
10 files changed, 103 insertions(+), 39 deletions(-)
James
On Sat, 20 Jan 2024 at 07:26, James Bottomley
<[email protected]> wrote:
>
> As requested, I did a longer extension of my gpg keys, so my key needs
> refreshing, before you pull, to fix the expiry date. You can get my
> updates via DANE using:
>
> gpg --auto-key-locate dane --recv D5606E73C8B46271BEAD9ADF814AE47C214854D6
No I can't.
I get
$ gpg --auto-key-locate dane --recv D5606E73C8B46271BEAD9ADF814AE47C214854D6
gpg: key 814AE47C214854D6: "James Bottomley
<[email protected]>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
Fine - maybe I already had the update from the last time...
But no:
git log --show-signature
says
commit c25b24fa72c734f8cd6c31a13548013263b26286 (HEAD -> master)
merged tag 'scsi-misc'
gpg: Signature made Sat 20 Jan 2024 07:22:08 PST
gpg: using ECDSA key E76040DB76CA3D176708F9AAE742C94CEE98AC85
gpg: issuer "[email protected]"
gpg: Good signature from "James Bottomley
<[email protected]>" [full]
gpg: aka "James Bottomley <[email protected]>" [full]
gpg: aka "[jpeg image of size 5254]" [full]
gpg: aka "James Bottomley <[email protected]>" [unknown]
gpg: aka "James Bottomley <[email protected]>" [unknown]
gpg: Note: This key has expired!
Primary key fingerprint: D560 6E73 C8B4 6271 BEAD 9ADF 814A E47C 2148 54D6
Subkey fingerprint: E760 40DB 76CA 3D17 6708 F9AA E742 C94C EE98 AC85
and fighting that ^&%%$^ gpg command to try to figure out why, I still see
gpg: Note: signature key E742C94CEE98AC85 expired 2024-01-16 11:39:15
sub nistp256 2018-01-23 [S] [expired: 2024-01-16]
E760 40DB 76CA 3D17 6708 F9AA E742 C94C EE98 AC85
and that's the one you signed with.
This mess continues to happen only with your crazy setup.
Linus
The pull request you sent on Sat, 20 Jan 2024 10:26:03 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c25b24fa72c734f8cd6c31a13548013263b26286
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Sat, 2024-01-20 at 09:52 -0800, Linus Torvalds wrote:
> On Sat, 20 Jan 2024 at 07:26, James Bottomley
> <[email protected]> wrote:
> >
> > As requested, I did a longer extension of my gpg keys, so my key
> > needs
> > refreshing, before you pull, to fix the expiry date. You can get
> > my
> > updates via DANE using:
> >
> > gpg --auto-key-locate dane --recv
> > D5606E73C8B46271BEAD9ADF814AE47C214854D6
>
> No I can't.
So this one looks to be a DNS issue. The secondaries on infradead.org
hadn't picked up the update (they were still showing old serial numbers
for the domain). I've force pushed an update (and verified the new
serial) so if you have the patience to retry, it should work now
(fingers crossed).
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 [email protected]
James
On Sat, 20 Jan 2024 at 11:09, James Bottomley
<[email protected]> 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 [email protected]
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
On Sat, 2024-01-20 at 11:35 -0800, Linus Torvalds wrote:
> On Sat, 20 Jan 2024 at 11:09, James Bottomley
> <[email protected]> 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
> > [email protected]
>
> 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"?
I can't extend the expiration longer than that of my main key
(apparently I created it in 2011 with a 25 year expiration ... that
seemed like infinity at the time, right). I think I can also extend
it but that's more of a virtuoso gpg manoeuvre, so I thought I wouldn't
try that in case it failed spectacularly and you were less than patient
..
James
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 [email protected] 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
On Sun, 2024-01-21 at 01:30 -0500, Theodore Ts'o wrote:
> Unlike James, I've tried to use DANE, since about the only thing that
^
never?
> 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....
Well the theory is sound: if the DNS is secure and trustworthy, getting
the gpg key from the same domain as the email records proves the tie
between the uid and the key (obviating the need for all this keysigning
and web of trust). Making DNS substitute for all these stupid external
CAs for web certificates as well (via DANE export of the X509 public
key) is also a good idea, as is exporting the ssh host keys and things.
However, having maintained DNSSEC for almost a decade now, I'm not
going to pretend it's something a non-expert sysadmin should be trying:
it's very particular and problems are hard to debug; you really have to
be in the top tier of expert sysadmins to be successful with it.
However, once it is running, bind9 now takes much of the pain out of
rolling the domain keys and, if you run a dynamic domain (one that can
be updated with nsupdate), you can actually give all your users scoped
permission to update their own key records, so if you have an expert
sysadmin on the domain, they can make DANE usable for all the non
experts.
I think the gpg usability problem is that I can't mark my key as being
DANE available in the key itself, so gpg would just automatically check
the DNS for an update and throw a warning if there was a DNS problem
(but still use the cached key). The failure is the users having to
figure out that my key is DANE available and then what combinatoric
explosion of gpg options they actually need to update it.
James
On Sat, 20 Jan 2024 at 22:30, Theodore Ts'o <[email protected]> wrote:
>
> Linus, you haven't been complaining about my key, which hopefully
> means that I'm not causing you headaches
Well, honestly, while I pointed out that if everybody was expiring
keys, I'd have this headache once or twice a week, the reality is that
pretty much nobody is. There's James, you, and a handful of others.
So in practice, I hit this every couple of months, not weekly. And if
I can pick up updates from the usual sources, it's all fine. James'
setup just doesn't match anybody elses, so it's grating.
I do end up having a fair number of signatures that show up as expired
for me in the tree. Some may well be because it's literally an old key
that has been left behind - it may have been fine at the time, but now
it shows as expired. It is what it is, and I'm not going to worry
about it.
But every time I do a pull, and the key doesn't verify, my git hook
gives me a warning, and so those things are a somewhat regular
annoyance just because then I have to go and check.
And I just checked: with James key now fixed, it's currently just
Alexander Gordeev that shows up as recently expired with me not
knowing where to get an update.
That key expired two days ago - I'm pretty sure it was fine last pull.
Alexander?
Linus
On Sun, Jan 21, 2024 at 10:48:35AM -0800, Linus Torvalds wrote:
> On Sat, 20 Jan 2024 at 22:30, Theodore Ts'o <[email protected]> wrote:
> >
> > Linus, you haven't been complaining about my key, which hopefully
> > means that I'm not causing you headaches
>
> Well, honestly, while I pointed out that if everybody was expiring
> keys, I'd have this headache once or twice a week, the reality is that
> pretty much nobody is. There's James, you, and a handful of others.
>
> So in practice, I hit this every couple of months, not weekly. And if
> I can pick up updates from the usual sources, it's all fine. James'
> setup just doesn't match anybody elses, so it's grating.
If we told those people who wantg to pursue key rotation to just
always upload keys to the Kernel keyring, using the instructions
here[1], and at the beginning of each merge window, you updated your
local clone of the kernel keyring git repo[2], and then ran the
scripts/korg-refresh-keys, the headache to you would be limited to
running "cd ~/git/korg-pgpkeys ; git pull ;
/scripts/korg-refresh-keys" every 2 or 3 months. The work you'd have
to do would be a fixed amount of work, even if more people were using
PGP key rotation.
[1] https://korg.docs.kernel.org/pgpkeys.html
[2] https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Would that be an acceptable (hopefully minimal!) amount of annoyance
for you?
- Ted
On Tue, 23 Jan 2024 at 21:36, Theodore Ts'o <[email protected]> wrote:
>
> If we told those people who wantg to pursue key rotation to just
> always upload keys to the Kernel keyring [..]
As long as the keys exist in the kernel.org keyring, it's all good.
That said, I still claim that nobody has *ever* had a valid and
meaningful reason to have expiry dates, so I want to stop you right
there when you talk about "people who want to pursue key rotation".
The absolute *first* thing you should tell those people is "Why? Don't
bother, it's just added pain for no gain".
It's like revocation keys. To a very close approximation, never in the
history of the universe have they been useful and meaningful.
The fact that the keyservers don't even work any more have made them
even less so, since now the revocations will never really spread
anyway.
So no. Let's not encourage people to do this silly thing.
If you ABSOLUTELY HAVE TO have expiration dates and other silly games,
yes, I will complain if I can't then easily get your key from the
single reliably working remaining setup.
But if you cannot explain exactly why you absolutely need to do it and
have some external entity that forces you to do silly things ("Your
daughter has been kidnapped, and you're not Liam Neeson"), the answer
should not be "remember to update the key at kernel.org", but simply a
plain "DON'T".
Linus