Can you rebase this against release-23.05 please? I don't think this technically meets the backporting guidelines but 🤷‍♀️

Ah, you're correct, this is the wrong branch (luckily the automated checks caught it :) )

I don't think this technically meets the backporting guidelines

It absolutely does. What in the guidelines do you think this goes against? (for reference: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#changes-acceptable-for-releases)

@delroth Each commit should be individually cherry picked with a reference to the original commit (-x), I don't think there's generally any exceptions to doing that when backporting changes as in this PR, rather than e.g. pulling in a singular patch to address security issues.

@delroth Each commit should be individually cherry picked with a reference to the original commit (-x), I don't think there's generally any exceptions to doing that when backporting changes as in this PR, rather than e.g. pulling in a singular patch to address security issues.

Ah, I see what you mean - thanks for bringing this up. I don't think the guidelines explicitly require this per se, but it's indeed heavily recommended when the cherry picks do apply cleanly. In a case like this I don't think I have a strong preference between cherry-picking the missing series of bumps vs. just squashing it into one big commit, and I don't think this has ever come up as "something one shouldn't do" in any previous backport PR I've dealt with.

I'll bring that up on Matrix to see if others have opinions.

(Actually, I can fix that myself, heh.)

The opinions I got on Matrix didn't suggest that the way this backport was done should be blocking anything, so merging this to try and move the vuln remediation forward.