3 ms·

Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Pytho

Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code. Depending on how and where you deploy, you can mitigate some of that by isolating the installs and not keeping sensitive information there (e.g. in a docker image). [1] - I don't follow node/npm closely anymore, so this may have changed.

louislang 3y ago
this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.
- PuercoPop 3y ago
  For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust. And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines. For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory. I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)
  - mensfeld 2y ago
    Hey, you have to patch nothing. Nix support was merged to karafka two months ago.
Denvercoder9 3y ago
I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?
- taeric 3y ago
  Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace. More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)
  - dns_snek 3y ago
    How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it. In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.
    - taeric 3y ago
      Honestly, I'm going off memory on python. In the olden days, it was not at all uncommon for devs to want the ability to "sudo pip install foo".
  - Denvercoder9 3y ago
    Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.

louislang 3y ago

this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.

PuercoPop 3y ago
For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust. And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines. For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory. I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)
- mensfeld 2y ago
  Hey, you have to patch nothing. Nix support was merged to karafka two months ago.

Denvercoder9 3y ago

I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?

taeric 3y ago
Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace. More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)
- dns_snek 3y ago
  How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it. In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.
  - taeric 3y ago
    Honestly, I'm going off memory on python. In the olden days, it was not at all uncommon for devs to want the ability to "sudo pip install foo".
- Denvercoder9 3y ago
  Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.