3 ms·

Yeah I think it's totally insane. If your package requires a system dependency, like a binary, it should simply fail to install and let you know that you should

Yeah I think it's totally insane. If your package requires a system dependency, like a binary, it should simply fail to install and let you know that you should go get that dependency. It should not, instead, require root privileges to add that to your system. Or, we should be providing virtualization like containers so that it can do 'root-y things' safely.

Kalium 7y ago
It sounds like you're describing snap packages. Is that accurate? That mostly works for whole applications. I'm not sure how to apply it to libraries for developers though. Especially ones that would get installed in userspace, like these python packages.
- staticassertion 7y ago
  I'm not super familiar with snap, my weak understanding is that it makes for a very poor isolation boundary.
  - Kalium 7y ago
    Yup, in large part because users expect things to work across the boundary.
dylan-m 7y ago
I've been having a happy time putting together a BuildStream project (https://buildstream.build/ https://buildstream.build/). It's meant for integrating packages into a larger system, for instance Flatpak runtimes and Linux system images, but it happens to do a really good job of this because every component is built in its own sandbox - with zero internet access, because they're going for reproducible builds. (Go to a commit from two years ago, build it, and you should get the same output you did back then). This means you have to obsessively specify dependencies, including exactly which files to fetch from the internet and which system components are required. And it also means some lovely security wins. For instance, if everyone lost their minds and decided that we should wrap all of our Python packages with BuildStream metadata and build everything that way, a build-time attack would be extremely difficult :) Of course, said library could do whatever evil it wishes for end users, but I guess the interesting lesson here is that the steps required for sandboxing can have genuine benefits outside of security, as well.

Kalium 7y ago

It sounds like you're describing snap packages. Is that accurate? That mostly works for whole applications. I'm not sure how to apply it to libraries for developers though. Especially ones that would get installed in userspace, like these python packages.

staticassertion 7y ago
I'm not super familiar with snap, my weak understanding is that it makes for a very poor isolation boundary.
- Kalium 7y ago
  Yup, in large part because users expect things to work across the boundary.

dylan-m 7y ago

I've been having a happy time putting together a BuildStream project (https://buildstream.build/ https://buildstream.build/). It's meant for integrating packages into a larger system, for instance Flatpak runtimes and Linux system images, but it happens to do a really good job of this because every component is built in its own sandbox - with zero internet access, because they're going for reproducible builds. (Go to a commit from two years ago, build it, and you should get the same output you did back then). This means you have to obsessively specify dependencies, including exactly which files to fetch from the internet and which system components are required. And it also means some lovely security wins. For instance, if everyone lost their minds and decided that we should wrap all of our Python packages with BuildStream metadata and build everything that way, a build-time attack would be extremely difficult :) Of course, said library could do whatever evil it wishes for end users, but I guess the interesting lesson here is that the steps required for sandboxing can have genuine benefits outside of security, as well.