this post was submitted on 08 Apr 2024
107 points (87.4% liked)

Linux

48295 readers
783 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r
107
How the xz backdoor highlights a major flaw in Nix (shadeyg56.vercel.app)
submitted 7 months ago* (last edited 7 months ago) by d3Xt3r to c/linux@lemmy.ml
29 comments fedilink hide all child comments
 

The main issue is the handling of security updates within the Nixpkgs ecosystem, which relies on Nix's CI system, Hydra, to test and build packages. Due to the extensive number of packages in the Nixpkgs repository, the process can be slow, causing delays in the release of updates. As an example, the updated xz 5.4.6 package took nearly 5 days to become available in the unstable branch!

Fundamentally, there needs to be a change in how security fixes are handled in Hydra. As stated in the article, Nix was lucky to be unaffected, but multiple days to push out a security patch of this severity is concerning, even if there was no reason for concern.

you are viewing a single comment's thread
view the rest of the comments
[–] 0xtero@beehaw.org 28 points 7 months ago* (last edited 7 months ago) (4 children)

Kinda tired of the constant flow of endless "analysis" of xz at this point.
There's no real good solution to "upstream gets owned by evil nation state maintainer" - especially when they run it in multi-year op.

It simply doesn't matter what downstream does if the upstream build systems get owned without anyone noticing. We're fucked.

Debian's build chroots were running Sid - so they stopped it all. They analyzed and there was some work done with reproducible builds (which is a good idea for distro maintainers). Pushing out security updates when you don't trust your build system is silly. Yeah, fast security updates are nice, but it took multiple days to reverse the exploit, this wasn't easy.

Bottom line, don't run bleeding edge distros in prod.

We got very lucky with xz. We might not be as lucky with the next one (or the ones in the past).

[–] PotatoesFall@discuss.tchncs.de 12 points 7 months ago (1 children)

I think the post was more about pointing out how long it takes to put out a security patch. Security patches can also occur on stable.

[–] 0xtero@beehaw.org 2 points 7 months ago

Yeah, I can get that. The xv situation probably wasn't the best of examples though?

[–] biribiri11@lemmy.ml 5 points 7 months ago

We might not be as lucky with the next one (or the ones in the past).

Or the ones in the present, for what that’s worth

[–] qwesx@kbin.social 2 points 7 months ago (1 children)

Maybe you should actually have read OP's post.

[–] 0xtero@beehaw.org 5 points 7 months ago* (last edited 7 months ago)

I'm not sure why you think I didn't? Sorry if it was unclear.

From the blog:

This incident has really made me wonder if running the unstable branch is a great idea or not.

My comment:

Bottom line, don’t run bleeding edge distros in prod.

Hope this clarified my opinion! Have a good day!

[–] Nomad@infosec.pub 1 points 7 months ago

Bottom line, don't run bleeding edge distros in prod.

This. My company's servers are all Debian stable. Not even sweating the issue.