19.12.2013, 07:18, "Nuno Job" <[email protected]>:
Google "nodejs lockdown lloyd"That should be easy enough to get started
You're right, that one should probably be merged with npm shrinkwrap.
Ideally modules should be signed by author and a couple more people to validate origin.
Author only. Public keys are leaked much less frequently than passwords, so bothering other people don't make sense.
Nodejitsu sells a private npm product, with it comes full control over all things
PaaS are evil.
You are right to be concerned: anyone that has a module you use can effectively attack you. All it takes is for their credentials to be compromised, credentials which I believe are just a plain text file on your home. I've raised this issues more than 2 years ago and it seems be a recurring one right now. So understanding this is how npm works and creating security validation processes for your releases is a good idea
... and credentials that gets passed over a network very frequently. I wonder, is there a way around add-auth=true for private registries?
Anyway, I submitted a pull request 2 months ago, but it didn't bring much attention:
https://github.com/isaacs/npm/pull/4016
And it doesn't solve all of the issues. I wonder if it makes sense to start a discussion about it again, especially considering the fact that there are public replicas like npmjs.eu, and although I very much want to use them, lack of package verification makes me sad.
You can also check the node security project
Is it still alive? There is some activity on twitter, but otherwise the site is pretty much empty.
--Hope this is helpfulNunoOn Thursday, December 19, 2013, Alex Kocharin wrote:No idea why. I think it would be reasonable for npm registry to allow unpublishing, but deny republishing an exactly the same version number afterwards. So if something needs to be republished, maintainer will be forced to change version number (or add a build number although it's now ignored by npm).You can try to use caching npm registry, for example this one:It wasn't specifically created for ensuring immutability, but it's a nice side effect. Once certain package (tarball) is cached there, all subsequent changes in npm registry will simply be ignored. This way I was able to detect changes in bson v0.2.3 deep inside our dependency tree, although nothing harmful was there.Anyway, if you're thinking about security, I'd suggest to bring up another issue. Signed packages. Without them it's hard to rely even on your own published packages. Although I'm not quite sure how to implement this properly, I feel it really needs some attention.18.12.2013, 16:23, "Richard Marr" <[email protected]>:I'm working on an app where security is an issue, and among the (many) things that I'm frothingly paranoid about is the possibility of malicious (or more likely just untested) code somehow getting into our app, even though we're using shrink-wrapped versions. It means we'll have to be much more careful with the way we proxy the npm registry.
This is probably a stupid/tired question, but why does npm allow mutable packages?As a secondary point, I would have thought immutable packages would allow for much better caching behaviour, so reduce load on the registry itself and speed up npm for everybody.
--
Richard Marr--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
