Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Support signed releases #1197

Closed
braydonf opened this issue Apr 22, 2020 · 1 comment
Closed

[FEATURE] Support signed releases #1197

braydonf opened this issue Apr 22, 2020 · 1 comment
Labels
Enhancement new feature or improvement

Comments

@braydonf
Copy link

Why

There have been a number security incidents with regard to the security of dependencies, to cite a few:

It's often recommended to use a package-lock.json for mitigation. However this approach is limited:

  • While a package-lock.json file ensures integrity it only applies to cases in which the dependencies are installed from the root of a package, and not when that dependency is added to an existing package as a dependency in package.json. A shrinkwrap.json file can help to resolve the former, as well as bundling the dependencies using bundleDependencies. However then there is the case that dependencies should be deduplicated, and that shrinkwrap.json file would no-longer be relevant.
  • A package-lock.json and shrinkwrap.json do not apply to upgrading a dependency, to which is another opportunity for a dependency to underhandedly include some malicious code. And considering that many changes to a package-lock.json can be fairly large, it's very likely that those changes actually do not get the review that is necessary.
  • There is still a fair amount of use of standard sha1 for integrity, which has been considered insecure for quite some time. These risks can be mitigated with using sha1 collision detection as being used with git.

To mitigate risks with dependencies, supporting signed releases can reduce the surface area of attack and that a dependency has been released by the intended release maintainer of a dependency. Given that many releases are already being signed with git, this is already part of a release maintenance process and could be supported with minimal changes.

How

I've researched a solution that will work today using existing signed git tags. To illustrate this, I've implemented that functionality at: https://github.com/braydonf/gpk

@darcyclarke darcyclarke added the Enhancement new feature or improvement label Oct 30, 2020
@darcyclarke
Copy link
Contributor

npm v6 is no longer in active development; We will continue to push security releases to v6 at our team's discretion as-per our Support Policy.

If your bug is reproducible on v7, please re-file this issue using our new issue template.

If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo

Closing: This is an automated message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement new feature or improvement
Projects
None yet
Development

No branches or pull requests

2 participants