util-linux: 2.39.3 -> 2.40.1

[alyssais]

Description of changes

CVE-2024-28085 (low priority since NixOS doesn't make wall setgid by default).

Release notes

• 2.40
• 2.40.1

Don't see anything looking like a breaking change.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[alyssais]

Security backport for stable: #309808

[06kellyjac]

Is the liblastlog2 and pam_lastlog2 dependency on sqlite always necessary or only for with pamSupport?

LGTM

[alyssais]

Is the liblastlog2 and pam_lastlog2 dependency on sqlite always necessary or only for with pamSupport?

If I'm reading correctly, it's possible to build liblastlog2 without building pam_lastlog2. We could add an option to disable it, but I don't know how to decide whether that's worth it.

[vcunat]

For reference, the parallel build is a bit flaky now:

/nix/store/bgcaxhhxswzvmxjbbgvvaximm5hwghz1-binutils-2.41/bin/ld: cannot find -llastlog2: No such file or directory
collect2: error: ld returned 1 exit status
libtool:   error: error: relink 'pam_lastlog2.la' with the above command before installing it

[alyssais]

Time to switch to Meson?

[vcunat]

It feels late for 24.05. But fortunately adding meson+ninja wouldn't create an eval-time cycle here.

[alyssais]

Reported, also.

[vcunat]

And (aarch64-)darwin build regressed on this update with a different error now: https://hydra.nixos.org/build/260146685

libuuid/src/uuid_time.c:89:87: error: aliases are not supported on darwin

EDIT: util-linux/util-linux#3013

[vcunat]

Oh, that darwin issue would even become a blocker for nixpkgs-unstable channel :-/

[alyssais]

There's also a bug report here: util-linux/util-linux#3011.

[vcunat]

Man, x86_64-darwin sports yet another error:

libsmartcols/src/filter.c:194:14: error: call to undeclared function 'fmemopen'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        fltr->src = fmemopen((void *) str, strlen(str), "r");
                    ^

(IIRC older macOS doesn't provide this function yet)

[vcunat]

Quite a bad luck with this release, and in the last moments before nixpkgs "freeze".

[alyssais]

I really wish OfBorg was capable of getting past LLVM on staging for Darwin…

[vcunat]

If it was so easy, we perhaps wouldn't even need staging*.

[alyssais]

It gets most of the way through — we just need to up the timeout a bit, and then I think OfBorg might even be less overloaded, because it wouldn't be wasting so much of its time trying the same futile LLVM builds over and over.

[vcunat]

Maybe we should just roll back to util-linux 2.39.x for now and keep nixpkgs 24.05 that way? (darwin now, linux on the next rebuild)

[alyssais]

Sounds fine.

[alyssais]

We should probably cherry-pick #309808 in that case.

[vcunat]

Perhaps 2.39.4 instead, as it sounds minimal and should contain also that fix
https://github.com/util-linux/util-linux/blob/v2.39.4/Documentation/releases/v2.39.4-ReleaseNotes

[alyssais]

Ah yes, that sounds good. I missed that.

[vcunat]

For reference, 2.40.1 also broke its static musl build:
https://hydra.nixos.org/build/259722977

[alyssais]

That's likely easily fixed by just disabling the PAM plugin on static builds. But is there any point fixing that, even on staging, or will we revert this there as well?

[vcunat]

Right, not now. I've given up on fixing 2.40.x for nixpkgs 24.05.

[alyssais]

I mean what about staging? i.e. post 24.05

[alyssais]

I guess it'd just cause merge conflicts, since the gradual reversion on staging-next will propagate to staging.

So for future reference when we come back to 2.40, here's the diff for static:

diff --git i/pkgs/os-specific/linux/util-linux/default.nix w/pkgs/os-specific/linux/util-linux/default.nix
index 642480b670c7..169f8293ae3e 100644
--- i/pkgs/os-specific/linux/util-linux/default.nix
+++ w/pkgs/os-specific/linux/util-linux/default.nix
@@ -6,6 +6,7 @@
 , ncursesSupport ? true
 , ncurses
 , pamSupport ? true
+, pamLastlogSupport ? pamSupport && !stdenv.hostPlatform.isStatic
 , pam
 , systemdSupport ? lib.meta.availableOn stdenv.hostPlatform systemd
 , systemd
@@ -61,6 +62,7 @@ stdenv.mkDerivation rec {
     "--disable-makeinstall-setuid" "--disable-makeinstall-chown"
     "--disable-su" # provided by shadow
     "--with-tmpfilesdir=${placeholder "out"}/lib/tmpfiles.d"
+    (lib.enableFeature pamLastlogSupport "pam-lastlog2")
     (lib.enableFeature writeSupport "write")
     (lib.enableFeature nlsSupport "nls")
     (lib.withFeature ncursesSupport "ncursesw")

[leona-ya]

For context: This update also caused a regression with detecting the UUID of some special LUKS devices (maybe only if the LUKS device contains a LVM). I haven't reported this upstream yet, will do later.
Some more context is in https://discourse.nixos.org/t/nixos-24-05-upgrade-no-boot-device/46335, which is quite analogous to what I experienced.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixos-24-05-upgrade-no-boot-device/46335/3

[YellowOnion]

bcachefs-tools on master needs util-linux/util-linux#3001 to detect my disks correctly, not a huge issue, but worth noting for future potential issues if that makes it in to nixpkgs-unstable before this does.

[alyssais]

We can backport that patch.