4 ms·

Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that

by Kalium 7y ago

Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that should not have to be defined in advance for a given package. The result has been a very hands-off approach. Package management systems for user-land libraries, like pip and so on, are extra guilty of being hands-off. And who wants their dev tools telling them what they can and can't do?

staticassertion 7y ago
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.

by Kalium 7y ago

staticassertion 7y ago

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.