3 ms·

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/n

by totony 5y ago

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 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.

Ericson2314 5y ago
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.
- totony 5y ago
  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.
catern 5y ago
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.
- totony 5y ago
  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.
  - easygenes 5y ago
    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.

by totony 5y ago

Ericson2314 5y ago

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.

totony 5y ago
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.

catern 5y ago

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.

totony 5y ago
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.
- easygenes 5y ago
  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.