5 ms·

Well, there goes `nixos-unstable`

nextaccountic 3y ago
Pulling directly from github is probably not a good thing either way. Maybe nixos should have its own mirror. Or maybe there should be an ipfs mirror that some distros and other projects could seed Anyway I think that a new release that fixes the known vuln isn't enough. There should be a release without all contributions from the malicious dude
- deleted 3y ago
  [deleted]
- rurban 3y ago
  Pulling directly from github is the good thing. The release tar was compromised, the sources not.
  - nextaccountic 3y ago
    In this specific case this is true, but generally speaking Github can remove repositories for any reason (and for no reason). They provide free bandwidth so it gets used for that, it's just not trustworthy. One option for distros that compile from source (such as Gentoo, NixOS without the package cache, of Arch Linux's AUR) is to make the package system to either download from Github, or download from a distro-provided mirror if Github is down. Distros could pool together to offer a source code mirror that is common for all their users. That would be a good thing.
1attice 3y ago
Less puckishly: in general, as a movement/culture/economic ferment, we probably should have been more hesitant to introduce a de-facto single-point-of-failure into, like, all the things. I mean, nothing _mandates_ that NixOS packages pull their source from github (or any other git hoster) but the standard practice is basically just this. The nix cache will prevent the impact from this specific disablement from being, well, disabling, for most folks most of the time, for a while at least, but caching, by definition, is ephemeral storage, and sooner or later, it, ah, ephemes? Is that a word? There are also a lot of packages that have to be built locally, e.g. nonfree packages like nvidia drivers; at least _one_ of these packages (how popular? how critical?) will probably fail to build on this account, and this in turn will cause a certain (unknown) quotient of misery. Somewhere, some lights are going out. (How many? How soon? With what mitigation?) Anyway. Nix is obviously not the only product to rely on github as a de facto backing store, so
- anon25783 3y ago
  Yes! There are alternatives to Github, people! Diversify! Switch to Sourcehut or Gitea or Gitlab or even DIY with Gitolite. git is a decentralized peer-to-peer system, we shouldn't let Microsoft have a monopoly on its use.
  - Dylan16807 3y ago
    That works if you have multiple mirrors configured for each package. Just adding variety reduces the chance of having all the important repos up at the same time.
    - 1attice 3y ago
      > Just adding variety reduces the chance of having all the important repos up at the same time. this, sadly, is correct, and the solution you propose is also correct. The only other option would be for the NixOS Foundation to mirror the git repo of _every single important package_, and I know they're already struggling with the prohibitive cloud costs of hosting just the build objects. :/
      - kelnos 3y ago
        They could mirror them on gitlab.com if they wanted to. It wouldn't even be that difficult to set up and automate.
  - sunshowers 3y ago
    I think this attitude really underrates the network effects of GitHub. I personally am okay making an account on another forge to submit a bug report or patch, but most people aren't. And so I keep my repos on GitHub. I do plan to soon set up mirroring to another service though. I haven't found a great zero-effort solution to mirror repos from an entire organization though, including ones that are created after mirroring was initially set up. Do you know of any tools which have that functionality? (If not I might write my own at some point.)
anotherhue 3y ago
> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.[0] A quick glance at nixpkgs[1] does not show a direct dependency. 0: https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4 1: https://github.com/NixOS/nixpkgs/tree/master/pkgs/tools/networking/openssh https://github.com/NixOS/nixpkgs/tree/master/pkgs/tools/netw...
- 1attice 3y ago
  True, but irrelevant -- _some packages_, _somewhere_, do depend on xz, which, if built, requires pulling the source from GitHub (see the default.nix: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/compression/xz/default.nix#L60 https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/to...) It's not the vulnerability that's a problem right now (NixOS was protected by a couple of factors) but rather GitHub's hamfisted response. That is the problem.
  - dave_universetf 3y ago
    It's not a problem, never has been. Nix mirrors all source bundles it pulls from third parties and caches them. cache.nixos.org has a copy of all the sources needed to build not just current HEAD, but also past commits (although deep history might start getting pruned for cost control soon, iiuc). The Software Heritage archive also has an up to date mirror of xz's repo: https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/tukaani-project/xz https://archive.softwareheritage.org/browse/origin/directory...
    - dwattttt 3y ago
      In this instance then, it sounds like it has cached the source with a backdoor in it, and anyone using it is potentially exposing themselves to a very public problem right now.
      - 3y ago

Pulling directly from github is probably not a good thing either way. Maybe nixos should have its own mirror. Or maybe there should be an ipfs mirror that some distros and other projects could seed Anyway I think that a new release that fixes the known vuln isn't enough. There should be a release without all contributions from the malicious dude

deleted 3y ago
[deleted]
rurban 3y ago
Pulling directly from github is the good thing. The release tar was compromised, the sources not.
- nextaccountic 3y ago
  In this specific case this is true, but generally speaking Github can remove repositories for any reason (and for no reason). They provide free bandwidth so it gets used for that, it's just not trustworthy. One option for distros that compile from source (such as Gentoo, NixOS without the package cache, of Arch Linux's AUR) is to make the package system to either download from Github, or download from a distro-provided mirror if Github is down. Distros could pool together to offer a source code mirror that is common for all their users. That would be a good thing.

1attice 3y ago

Less puckishly: in general, as a movement/culture/economic ferment, we probably should have been more hesitant to introduce a de-facto single-point-of-failure into, like, all the things. I mean, nothing _mandates_ that NixOS packages pull their source from github (or any other git hoster) but the standard practice is basically just this. The nix cache will prevent the impact from this specific disablement from being, well, disabling, for most folks most of the time, for a while at least, but caching, by definition, is ephemeral storage, and sooner or later, it, ah, ephemes? Is that a word? There are also a lot of packages that have to be built locally, e.g. nonfree packages like nvidia drivers; at least _one_ of these packages (how popular? how critical?) will probably fail to build on this account, and this in turn will cause a certain (unknown) quotient of misery. Somewhere, some lights are going out. (How many? How soon? With what mitigation?) Anyway. Nix is obviously not the only product to rely on github as a de facto backing store, so

anon25783 3y ago
Yes! There are alternatives to Github, people! Diversify! Switch to Sourcehut or Gitea or Gitlab or even DIY with Gitolite. git is a decentralized peer-to-peer system, we shouldn't let Microsoft have a monopoly on its use.
- Dylan16807 3y ago
  That works if you have multiple mirrors configured for each package. Just adding variety reduces the chance of having all the important repos up at the same time.
  - 1attice 3y ago
    > Just adding variety reduces the chance of having all the important repos up at the same time. this, sadly, is correct, and the solution you propose is also correct. The only other option would be for the NixOS Foundation to mirror the git repo of _every single important package_, and I know they're already struggling with the prohibitive cloud costs of hosting just the build objects. :/
    - kelnos 3y ago
      They could mirror them on gitlab.com if they wanted to. It wouldn't even be that difficult to set up and automate.
- sunshowers 3y ago
  I think this attitude really underrates the network effects of GitHub. I personally am okay making an account on another forge to submit a bug report or patch, but most people aren't. And so I keep my repos on GitHub. I do plan to soon set up mirroring to another service though. I haven't found a great zero-effort solution to mirror repos from an entire organization though, including ones that are created after mirroring was initially set up. Do you know of any tools which have that functionality? (If not I might write my own at some point.)

anotherhue 3y ago

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.[0] A quick glance at nixpkgs[1] does not show a direct dependency. 0: https://www.openwall.com/lists/oss-security/2024/03/29/4 https://www.openwall.com/lists/oss-security/2024/03/29/4 1: https://github.com/NixOS/nixpkgs/tree/master/pkgs/tools/networking/openssh https://github.com/NixOS/nixpkgs/tree/master/pkgs/tools/netw...

1attice 3y ago
True, but irrelevant -- _some packages_, _somewhere_, do depend on xz, which, if built, requires pulling the source from GitHub (see the default.nix: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/compression/xz/default.nix#L60 https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/to...) It's not the vulnerability that's a problem right now (NixOS was protected by a couple of factors) but rather GitHub's hamfisted response. That is the problem.
- dave_universetf 3y ago
  It's not a problem, never has been. Nix mirrors all source bundles it pulls from third parties and caches them. cache.nixos.org has a copy of all the sources needed to build not just current HEAD, but also past commits (although deep history might start getting pruned for cost control soon, iiuc). The Software Heritage archive also has an up to date mirror of xz's repo: https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/tukaani-project/xz https://archive.softwareheritage.org/browse/origin/directory...
  - dwattttt 3y ago
    In this instance then, it sounds like it has cached the source with a backdoor in it, and anyone using it is potentially exposing themselves to a very public problem right now.
    - 3y ago