Signed and certified packages

[Ginden]

It should be possible for require function to validate required packages for their security.

Assume I'm running company that uses io.js for something important. We can't allow our programmists to use potentially dangerous (because of author pushing malicious package to npm or something) packages. These packages can be hidden deep in package dependencies.

I think it should be allowed to certify ("We, Code Review Company, guarantees it's valid and secure package") and sign packages using PGP keys. Moreover - it should be possible to have parameter (flag?) that allows requiring only safe packages (we have theirs public keys) and throws error when something requires potentially dangerous package.

It can result in increased adoption of io.js as trustworthy platfom.

[kenany]

I don't think require should be in charge of this. This seems more like an issue for npm, and in fact there are a couple of entries on the issue tracker regarding this (the integrity part of your request, at least): npm/npm#3252, npm/npm#4016.

[ruimarinho]

Agree with @kenany. I think this should be handled at the package manager layer.

[othiym23]

In fact, if you use npmE (and I'm sure there are other private registries and registry proxies that support this), there are already whitelist and blacklist features that give teams control over which packages can be used in their projects, set up in such a way that no packages that aren't on the approved list can even be installed within a protected intranet.

There have indeed been requests and proposals to come up with a general mechanism for package signing, and the main barrier there is the usual problem of how to authenticate signed packages without creating a usability and security nightmare. I think doing it at the package level is appropriate, though, because anything that's cryptographically secure is going to impose CPU overhead that's ridiculously high in the context of bringing up a web service in production.

[yurivict]

Why can't npm distribute the public key as part of its package, and sign all npm packages with the private key?

[indutny]

@yurivict In fact I thought about it too, but then I got distracted and never finished the: npm/npm-registry-client#43

[mbonaci]

Of course you can, but it's not in his employer's interest to do so, so he'll keep slipping you enterprise version and packaging the potential implementation in nightmares.
What about NPM foundation?

[yurivict]

I asked about package authentication here https://www.npmjs.com/support and here npm@npm.org, but can only hear this as an answer: https://www.youtube.com/watch?v=Re72di5phM0

[othiym23]

@isaacs, @seldo, and I have discussed adding package signing to npm, and have some tentative ideas about how it should be designed (probably more likely built on ssh keys than OpenPGP / GnuPG, for many, many reasons), but getting to that is a ways out, and is probably a ways behind getting more robust authentication to the registry.

[yurivict]

pgp is good for e-mail. But in respect of package signing, it depends what is meant here. If you are going to download pgp key from the public pgp server, this is also a security threat.

[timkuijsten]

@othiym23 maybe signify(1) is something usable. I know it's used with pkg_sign(1) and is licensed under ISC. See it's announcement from last year: http://www.undeadly.org/cgi?action=article&sid=20140121114349&mode=expanded&count=0

[rvagg]

This is something we're tinkering with at NodeSource, so pulling @bmeck in here at least so he knows this discussion exists.

[bmeck]

Yarrrr! Brain dump as follows (too tired to go into depth):

1. Developers hate signing things, we need to use keys that they already have. I have spoken to several people about this and I think _ssh keys_ are winning. Many different kinds of keys can even be used by reused as ssh keys which is a win.
2. Having require perform code signing on a per require basis is a bad idea, you want to perform the analysis on the whole of what you require, thus we would want signatures to be associated with the whole module tree (difficult without moving to archive files ala noda-loader. I am currently speccing out getting the loader to do signing, but have not gotten around to making anything
3. There are multiple points where signing is important as noted in this doc. We can associate module signing with some things, but signing an application in the same manner would most likely prove difficult since we generally want to associate with a certificate chain from the people I have talked to.
   1. There are also multiple definitions of deployable targets; we can ship a full archive of the compiled source, and there are several tactics to create single binary files. Our signing process should stay limited to the archives and leave binary signing to the tool of choice for the target os/arch.
   2. There is also a question of how to approve keys for usage, revocation lists might need to become prevalent and that is something that no one enjoys.
   3. There is a question about signing via groups, for example if a audit group signs modules as having been audited. To do this we would need to define our CA setup more in depth than just via keys.
4. IO.js and Node.js dist use pgp keys.

Feel free to mention me about various points that are brought up.

PS: Just say no to PGP unless you have to.