-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Comments
npm If your bug is reproducible on 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. |
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: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 inpackage.json
. Ashrinkwrap.json
file can help to resolve the former, as well as bundling the dependencies usingbundleDependencies
. However then there is the case that dependencies should be deduplicated, and thatshrinkwrap.json
file would no-longer be relevant.package-lock.json
andshrinkwrap.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 apackage-lock.json
can be fairly large, it's very likely that those changes actually do not get the review that is necessary.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
The text was updated successfully, but these errors were encountered: