search

alexanderGugel / ied

:package: Like npm, but faster - an alternative package manager for Node
http://alexandergugel.github.io/ied
MIT License
1.99k stars 53 forks source link

Optionally disable postinstallation hooks #99

Closed just-boris closed 8 years ago

just-boris commented 8 years ago

The thing that any package can execute arbitrary code during installation can be considered as a vulnerability. So it would be good to have the option to disable it. Even better, if it will be possible to configure white/black lists with packages.

NPM has a flag for it npm install --ignore-scripts. I think we should have the same.

Original source here: https://github.com/alexanderGugel/ied/pull/87#issuecomment-200490345

vladwing commented 8 years ago

I think it should be the default option, since most packages do not need life-cycle scripts.

The ones that have life-cycle scripts need to be added to a whitelist based on hash of the package that ied computes anyway. The whitelist should probably be user-wide or system-wide.

There also need to be a warning from the ied that scripts need to be run. Install needs to fail without the package being present in the whitelist or having specifically been installed with --ignore-scripts.

alexanderGugel commented 8 years ago

Definitely agree with @just-boris here. lifecycle scripts are always kinda dangerous... we should at least offer the option to disable them...

@vladwing Disabling all of them by default is going to be an unpopular opinion until we have the first npm worm that takes over half the internet.

vladwing commented 8 years ago

@alexanderGugel you are right. Maybe have a --secure option that can be saved user/system-wide and which disables lifecycle scripts unless the hash of the module is whitelisted. It will be easy to make that option the default later on.

STRML commented 8 years ago

I agree with this.

Let's enumerate the risk here so we know how to best address it:

The baseline risk is that a malicious package will spawn some processes, read/delete files, etc. All of this can be done upon an initial require(), but difference is in which user context it can do so.

It's (somewhat) common for some users to install packages as root but run the node process as a restricted user. It's very common to install global packages as root.

So we can do two things:

  1. Like homebrew, nag the user if they're intentionally/unintentionally running ied as root without the --global flag
  2. When installing packages as root, global or otherwise, require whitelisting packages that are allowed to run scripts. I would see this as a separate field in package.json, and an attribute in ied-shrinkwrap.json (when that comes, and when it does, it should specify @author:package@version::hash).
alexanderGugel commented 8 years ago

The rebirth branch has a --build flag that enables lifecycle scripts. I think making it opt-in is better due to the reasons mentioned above. https://github.com/alexanderGugel/ied/tree/rebirth

I will close this once rebirth is merged into master.

STRML commented 8 years ago

I think this is a good idea. Perhaps at the end of an install, we could list the packages with hooks that weren't run. Would simplify the process for the security-conscious. On Apr 13, 2016 7:36 AM, "Alexander Gugel" notifications@github.com wrote:

The rebirth branch has a --build flag that enables lifecycle scripts. I think making it opt-in is better due to the reasons mentioned above. https://github.com/alexanderGugel/ied/tree/rebirth

I will close this once rebirth is merged into master.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/alexanderGugel/ied/issues/99#issuecomment-209409137

alexanderGugel commented 8 years ago

Another option is to actually let the user select the hooks to be executed: https://www.npmjs.com/package/inquirer#checkbox---type-checkbox

vladwing commented 8 years ago

I have two issues with this approach:

  1. If we run "ied install" for a module, what happens with the half-installed packages(packages which had life-cycle scripts) that it required?
  2. How do we make it less painful for a user to choose which packages to run the life-cycle scripts for, in the above situation?

One additional thing: we should allow running, on a different switch, the life-cycle scripts for the root module. The reason is that maybe we disabled the scripts for its children, but the root module has some initialization for those to make them able to run.

alexanderGugel commented 8 years ago

Thanks everyone for this discussion. The current solution looks as follows:

  1. lifecycle scripts at opt-in, not opt-out via the --build flag
  2. in order to re-run lifecycle scripts, run ied install --build, which will as of 2.0.0 traverse the entire dependency graph (even for already installed dependencies) - I think that's what @vladwing meant, correct?
  3. lifecycle scripts are always run after all the packages have been installed