4 ms·

maybe it's time to push for adding signed packages to npm long discussion here: https://github.com/node-forward/discussions/issues/29 https://github.com/node-f

• edejong 9y ago
  I am very surprised that a package manager of this calibre and impact abstains from best practices when it comes to authentication through code-signing. Other package managers are miles ahead of NPM. For example, Nix, which uses immutability and hashing to always produce the same artifact, regardless of changes of the sources.
  • djsumdog 9y ago
    So I know rpms and debs are signed, as I've setup repos for both. Docker repositories require a valid SSL key (or you have to manually allow untrusted repos). But do Python packages and Ruby gems have signature verification? How does pypy/pip and gem deal with validating a package is what it claims to be?
    • viraptor 9y ago
      Traditional python packages support GPG signing: https://pypi.python.org/security https://pypi.python.org/security There's new experimental signing in wheels: https://wheel.readthedocs.io/en/stable/#automatically-sign-wheel-files https://wheel.readthedocs.io/en/stable/#automatically-sign-w... and the signing defined in PEP: https://www.python.org/dev/peps/pep-0427/#signed-wheel-files https://www.python.org/dev/peps/pep-0427/#signed-wheel-files
    • cpburns2009 9y ago
      PyPI (which is what Pip uses) at the very least does not require authors to sign their packages. I can't say whether it supports signing though.
    • ek750 9y ago
      Ruby gems can be signed but the percentage of gems authors taking advantage of that is low. At least we’ve got most people using https to transfer gems now!
  • johnny22 9y ago
    comparing distro package managers is a ton different than free for all spaces like packagist, ruby gems, pypi, npm, etc.
    • edejong 9y ago
      You have a point, but we need to take into account that the technology has been around for a long time, the risks are well known and documented, and safety concerns of most of these package managers have been addressed to maintainers. The example in the article has come to light accidentally, but we must seriously ask ourselves how many incidents are currently unidentified. Besides, you can use Nix for 'normal' development. It is suitable for more things than just a distro package manager.
• naasking 9y ago
  Signing won't help unless the end user specifies the signature or certificate that they expect (signing would only help ensure package upgrades are from the same author). If you're going to have clients specify a signature anyway, then you don't need to sign packages, you just need strong one way hash function, like SHA-1024 or something. User executes "pkg-mgr install [package name] ae36f862..." Either way, every tutorial using npm will become invalid.
  • 0x0 9y ago
    "npm install packagename" could record the public key in package.json (or package-lock.json) on first save, and only accept installs (or upgrades) matching the same public key. Just like how android app code signing works, or similar to ssh known_hosts trust-on-first-use. Granted it wouldn't save those adding a new package to a project the first time, but it would save the bacon of anyone re-running "npm install" in an existing project, for example during a deploy, or when trying to upgrade to a newer version of a given package.
    • naasking 9y ago
      > Granted it wouldn't save those adding a new package to a project the first time Right, that's the real problem.
      • no29 9y ago
        independent site that maps packages to author certs that npm uses for verification at install time? also, this is a problem that every package mgmt system faces. they alert on changes on upgrade but there's a requirement at the end user level to verify that at install time, the cert being trusted is the right one.
    • styfle 9y ago
      Would that mean a package with multiple authors would have to shared the private key with each other in order to publish a new version?