this post was submitted on 21 Apr 2024
120 points (87.0% liked)

Linux

47958 readers
1123 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
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 6 months ago (1 children)

Nix is already beyond fucked because they actively dismiss the need for appropriate security measures to prevent supply chain attacks. There were multiple discussions about this over the years that appear to have succumbed to neglect.

I wouldn't trust nix, just like I don't trust pip, brew, or a whole plethora of other package managers and repositories. They are just too neglectful

[–] [email protected] 2 points 6 months ago (1 children)
[–] [email protected] -1 points 6 months ago

If I were to fully elaborate, I'd be typing for hours, so I'll sum up:

  • pip - default behavior is to install to system-wide site packages. In a venv, it will try to upgrade/uninstall system packages without notice/consent unless you specify --require-virtualenv. Multiple things can fuck up your ENV to make the python binaries point to system-wide, while your terminal will still show you as in a venv. Also why TF would package metadata files need to be executable? Bad practice, -1/10
  • nix - they acknowledged years ago that they should probably have some kind of package signing and perhaps an SBOM or similar mechanism, but then did nothing to implement it and just said "oh well, guess we're vulnerable to supply chain attacks, best not to think about it"
  • brew - installing packages parallel to your system packages manager, without containers. My chief complaint here is that brew is a secondary package manager that people might treat as a "set and forget" for some packages, rarely updating them. So what happens when a standard library used by a brew package is vuln? A naive Linux user might update their system packages but totally forget to update brew. And when updating brew, you can easily hit max_open_file_descriptors because kitchen sink

From there, it's all extremely nit-picky and paranoid-fueled-- basically, none of the package managers I mentioned are conducive, in my eyes at least, to a secure and intuitive compute environment.

Unfortunately, there's not much I can do about it except bang pots and pans and throw maintainers under buses when the issue that has been present for years rears it's ugly head. Because they are the only ones who can change this, and pressure is the only thing that might motivate them to.