Critical correctness bug in Lix

Links
1
7 Likes
2

from the post i am not clear if this impacts nix as well as lix - can anyone please clarify?

thank you!

1 Like
4

The OP links a post with a bug introduced by the fix for the cve. The cve itself doesn’t tell if this bug introduced by the fix is unique to lix or also happens in nix and/or guix.

4 Likes
5

i read the entire blog post - see what @NobbZ says, he explains the situation well

thanks @NobbZ :heart:

6

Seeing as the security fix for Lix is apparently broken, has anyone figured out how apply the new fix?
(reference: Lix | Critical correctness bug in Lix)

I’ve tried switching from lix-module to the nixpkgs package using lixPackageSets.latest.lix.overrideAttrs, but I don’t think I’ve found the correct url for the patch yet (the only one I can find is https://gerrit.lix.systems/changes/lix~3510/revisions/7/patch?download and that fails in just patching version.json, which doesn’t seem correct - there should be more to patch and I also don’t get why the patch fails).
Then I’ve tried adding lix itself as a flake dependency, and using that as the input for lix-module, but I can’t seem to find the proper commit and branch to point at for lix as HEAD is at version 2.94.0-dev, but lix-module expects 2.93 and the lix branch release-2.93 doesn’t seem to have the update).

The simplest fix seems to be to patch the package in nixpkgs, like this, but as mentioned, the following doesn’t work:

  nix.package = pkgs.lixPackageSets.latest.lix.overrideAttrs (
    _finalAttrs: previousAttrs: {
      patches = (previousAttrs.patches or []) ++ [
        (pkgs.fetchpatch {
          url = "https://gerrit.lix.systems/changes/lix~3510/revisions/7/patch?download";
          decode = "base64 -d";
          hash = "sha256-3Lh2mvrJlw4TlmWehgYu8n6XypjFD62k0yd+3OsGENU=";
        })
      ];
    }
  );

Am I just bad at navigating gerrit? :sweat_smile:

7

I recommend to hold on for now, the new patch keeps the CVE closed but still breaks things, it overcorrects.

(We will also make it easier to navigate Gerrit and consume patches in the future for this sort of scenarios.)

2 Likes
8

So, is there a recommended rev to pin to for now? I’m currently running a generation with the bug, so I’d like to get my flake somewhere “safe” for now while we wait.

9

I recommend to revert to the previous (vulnerable) version as we are going to emit fixed versions very soon.
An alternative is to go for option B and revert only the offending patch in question.

1 Like
10

Could you help me with either? Which is the last vulnerable version? From what I see, the patch was applied to the last three versions. And for reverting the patch, I have the same issue as applying the patch above (I don’t know what the diff URL is)

11

Yes, of course: the last vulnerable versions are 2.91.1, 2.92.1, 2.93.0.

If you cannot access it, here is a code example to apply patches from Gerrit:

fixedLix = prev.lixPackageSets.latest.lix.overrideAttrs (
  oldAttrs: {
    patches = oldAttrs.patches ++ [
      (prev.fetchpatch {
        url = "https://gerrit.lix.systems/changes/lix~3518/revisions/3/patch?download";
        decode = "base64 --decode";
        hash = "sha256-uRWDA1ktyKvYmJu3yma9p0m+4U0PYWOPoxyrrsNGHv4=";
      })
    ];
  }
);

(courtesy of @teutat3s)

To avoid spamming this channel, I am available over Matrix in the Lix support channels, if you need synchronous help for this :).

3 Likes
12

The incident is now being closed as per Lix | Critical correctness bug in Lix, short of new critical reports.

If you are a Lix user affected, please reach out via the support channels to get help from the Lix team on how to recover your system.

We will now redirect our efforts to normal affairs and better recovery tools.

4 Likes