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

Invoke postinstallation hooks #87

Closed just-boris closed 8 years ago

just-boris commented 8 years ago

closes #82 Also, this feature was asked in #43 as the necessary thing to install electron-prebuilt.

It is not ready to merge, yet, I'd like just share my results, and I want to add more tests before this will be merged.

And there is a thing with native packages. They require node-gyp to be installed. NPM carries bundled node-gyp command. To get this work with IED, we need to install it: npm install -g node-gyp. Maybe it should be mentioned in the docs.

rauchg commented 8 years ago

+1

rauchg commented 8 years ago

@just-boris Just tested this on a local project for which ied was failing due to the lack of postinstall, and it worked like a charm! Thank you

alexanderGugel commented 8 years ago

That's really great! Big fan of this!

just-boris commented 8 years ago

The tests are lying, it is still not finished, but I made some progress there

just-boris commented 8 years ago

Fixed, the actual reason wasn't related to postinstall feature. I sent another pull request aimed to fix it: https://github.com/alexanderGugel/ied/pull/90

This PR is rebased and contains that fixes as well.

just-boris commented 8 years ago

@alexanderGugel it is ready to merge now :ship:

alexanderGugel commented 8 years ago

@just-boris Just merged the other PR. Will merge this one later today if possible. Thanks again!

just-boris commented 8 years ago

Well, got this, I am going to fix it on the next week, too many things to do at the current

just-boris commented 8 years ago

done

just-boris commented 8 years ago

@alexanderGugel ping

STRML commented 8 years ago

As ied is becoming a faster/higher security version of npm, might it make sense to offer a global flag to turn off postinstall hooks, or whitelist packages that are allowed to execute them?

alexanderGugel commented 8 years ago

@STRML Yes. postinstallation hooks (and lifecycle scripts in general) are in a sense a complete security fiasco IMO... I think they should actually be disabled by default....

I like this PR.

@just-boris Thanks for putting this together! Merged! Will be part of next release!

vladwing commented 8 years ago

@alexanderGugel if you disable life-cycle scripts, how can one install native modules? The person installing the npm module might not even know the module is half-installed.

alexanderGugel commented 8 years ago

@vladwing You would have to decide on a case by case basis whether or not you want to build those dependencies. It sucks, but the alternative is to just hope that none of those 300 maintainers that are behind the subdependencies or some package suddenly turn evil and decide to take over a thousand machines in a matter of hours. I'm surprised nobody has done that already.

vladwing commented 8 years ago

I totally agree it's wrong to allow code to run on your machine for no good reason. What I was suggesting is we need a way to alert that:

  1. the module has a native module it needs built
  2. the module has a native module it needs built and life-cycle scripts
  3. the module has life-cycle scripts, but no native modules

In that case ied should not install that module unless the user specifically permits it by adding its hash(not the package name/version anything else) to a whitelist.

How does it sound?

STRML commented 8 years ago

While npm is still dominant, that strategy seems fine, but if ied ever becomes popular, won't that just mean that a malware author has only a slightly higher bar to entry?

The idea of expecting every dev to audit all hooks also seems untenable. It's like we need a per-hash voting system. On Mar 23, 2016 10:45 PM, "Vlad Wing" notifications@github.com wrote:

I totally agree it's wrong to allow code to run on your machine for no good reason. What I was suggesting is we need a way to alert that:

  1. the module has a native module it needs built
  2. the module has a native module it needs built and life-cycle scripts
  3. the module has life-cycle scripts, but no native modules

In that case ied should not install that module unless the user specifically permits it by adding its hash(not the package name/version anything else) to a whitelist.

How does it sound?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/alexanderGugel/ied/pull/87#issuecomment-200644449

STRML commented 8 years ago

OTOH, are there actually things that a postinstall hook can do that a module can't do upon a require()? On Mar 23, 2016 10:59 PM, "Samuel Reed" samuel.trace.reed@gmail.com wrote:

While npm is still dominant, that strategy seems fine, but if ied ever becomes popular, won't that just mean that a malware author has only a slightly higher bar to entry?

The idea of expecting every dev to audit all hooks also seems untenable. It's like we need a per-hash voting system. On Mar 23, 2016 10:45 PM, "Vlad Wing" notifications@github.com wrote:

I totally agree it's wrong to allow code to run on your machine for no good reason. What I was suggesting is we need a way to alert that:

  1. the module has a native module it needs built
  2. the module has a native module it needs built and life-cycle scripts
  3. the module has life-cycle scripts, but no native modules

In that case ied should not install that module unless the user specifically permits it by adding its hash(not the package name/version anything else) to a whitelist.

How does it sound?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/alexanderGugel/ied/pull/87#issuecomment-200644449

just-boris commented 8 years ago

Let's move the discussion about it in the issue: https://github.com/alexanderGugel/ied/issues/99