I have went pretty deep in nix recently and imo the "Fixing other people's garbage is the bane of any package system maintainer, it's no different here" + high learning curve + lack of xattrs and permissions support in nix store makes it a bad OS. The amount of custom code to fix "issues" and "issues" that are only fixed because the maintainer thinks he knows better than the dev is too big to be maintainable. Still a good package manager for eg macOS if you dont need that.
> Fixing other people's garbage is the bane of any package system maintainer, it's no different here.
I honestly think it's hard for "Nix to Nix" simply because by trying to make everything reproducible, it is dealing with more of upstream's garbage, and "reifying" the hoops that people jump through doing sysadmin things in code looks scary.
I really want more upstream developers to use Nix, so they might loose their myopia, and start thinking of the the FOSS ecosystem as a whole, and not just their own packages within it. Nix is the best way to get the bird's eye view, I am sure. Just try not to gag at what you see!
[1] Though I still maintain that contributing to Nixpkgs is much easier than contributing to e.g. Debian or Fedora.
Yeah, exactly. Nixpkgs is basically the largest and most up to date repo in the Linux world now. Most of that’s coming just from the small existing core community. That has to say something for the efficiency of it.
Reproducibility is not the only issue they're facing. I think the mentality extends to more than just fixing linker issues, e.g. this https://github.com/NixOS/nixpkgs/issues/9656
At the end of the day, I much prefer trusting upstream than having to trust packagers to do everything right.
Having your screen locker which is written in C be setuid root is a really bad, really insecure idea. That it's supposedly being done for security reasons is replacing a minor, difficult to exploit security issue with something that's essentially guaranteed to be vulnerable.
Upstream is clearly wrong here - whether that means slock should be patched to be sane, or that slock should just not be packaged at all, I couldn't say.
The thread raises some valid points on both sides, but the slock issue is secondary to the real issue. Adding misc patches:
- Makes different systems behave differently - this makes bugs harder to track and confuses users
- Moves the trust from the software developer to both the software developer and packagers (who may not have the same expertise that the developer has)
For ex. #1: When you use software like slock, you presumably trust slock to do its job well. If you don't trust him enough in his choice to add setuid, then why would you trust him enough to use the screen locker?
I understand adding patches that are strictly packaging related if upstream is uncooperative (mostly I guess because nix is small), but changing behavior is another ballgame.
There's always been the tacit assumption that using a package manager implies trust in the way that packaging is handled by that manager. Often people who handle packaging dozens or hundreds of packages over years actually ARE much more aware of the security implications of decisions made by developers of individual pieces of software.
Fair, but at the same time, "setuid" is a war where everyone looses, IMO :).
Since the issue was first closed, there are some solutions for NixOS that I hope for discoverable. For Nixpkgs alone, I really don't think see any solution that is both secure and ergonomic -- setuid is bad.
Setuid has been replaced by capabilities, but nix faces the same struggles it has for setuid (only supports it through a wrapper, and that was after a "wontfix" according to the bug tracker).
More than that though, the mentality that you can just patch away critical features (like setuid) without telling the user is imo unhealthy for an OS.
