-
Notifications
You must be signed in to change notification settings - Fork 169
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
downloads package managers only from npm by default #495
Comments
The npm client also supports downloading from arbitrary URLs, if npm doesn't impose that restriction, it would be weird for Corepack to do IMO. |
For more context, I created the original issue #354 after the Node.js TSC meeting because some expressed that they didn't like the idea of corepack gatekeeping. |
The npm client does not download & execute libraries from the internet without telling its users. The gates here should be way tighter to guarantee the basic security of our users. |
? That does not seem to be the case $ mkdir repro && (cd repro && echo '{"dependencies":{"yarn":"https://registry.yarnpkg.com/yarn/-/yarn-1.22.22.tgz"}}' > package.json && npm i) && rm -r repro
added 1 package, and audited 2 packages in 2s
found 0 vulnerabilities No warnings at all, unless it's disabled in my env for some reason. What warning are you seeing? |
There are no warnings, but that is ok because the end user asked for it. Running |
Oh sorry for the confusion, I thought you were referring to the feature added in #359. |
I agree |
What do you mean? For whatever it's worth, the user is prompted if they want to download the package manager and where it's from: $ docker run --rm -it node:22 bash
$ corepack enable
$ yarn
! Corepack is about to download https://registry.yarnpkg.com/yarn/-/yarn-1.22.22.tgz
? Do you want to continue? [Y/n] |
Would the user know the risk this poses? That's my point. The message seems official and safe enough. |
@mcollina would adding to the wording help? Just for the sake of discussion would something like the following address your concern? The main reason I ask is to understand if its around the current message or something deeper? ! Corepack is about to download https://registry.yarnpkg.com/yarn/-/yarn-1.22.22.tgz. This is not part of the Node.js project and it's up to you in order to decide if this is safe to use. |
I think the messaging would help, but it's not enough. I think their package manager should:
I'm worried that a domain takeover in 2-3 years might cause issues. Considering that the yarn registry is currently a domain alias to npm, I think they could just switch to using npm there. (On a side note, yarn is signing their release with gpg, so I think this could easy be done). I also think that we should do this for all package managers, even those published to npm. The risk involved in running stuff almost automatically from the internet likes deserves this. |
Isn't it already the case? Packages that are published on the npm public registry are signed by npm, and Corepack verifies the signature if the user did not provide a hash. What more would you like to see?
Verifying PGP signature would require quite a lot of work – and probably a significant bundle size increase – on the Corepack side. I'd much rather prefer if they'd use an ECC signature as npm public registry does nowdays. |
This is sufficient. However, it does not certify that the bundle comes from the maintainers. I would generically prefer that (even for other modules that I download from npm). Using provenance/sigstore is kind of great, too. Anyhow, this is wishlist thing. My main concern is into having non-npm URLs in the default list. |
Guaranteeing that the build got authored by a known maintainer is a valid concern, but the place where those builds come from doesn't seem relevant once this check has been performed. |
If an attacker takes over the NPM domain, wouldn't it have the same implications, what's so special about non-NPM urls? |
Side note and since we're talking about security, it might also be worth to publish ref: https://github.blog/2023-04-19-introducing-npm-package-provenance/ |
Just a friendly reminder that there are large amounts of users in corporate environments that have no direct access to npmjs.org and need to rely on organization-internal proxy registries provided by Artifactory, Nexus, ProGet, etc. or even TLS-interception situations. Corepack has already proven to be a p.i.t.a. in those settings, but it has gotten somewhat better recently (with the exception of #479). Locking things down more generally means having to create more workarounds. So while providing extra security for the average Joe is probably a good idea, I hope it is done in a way that doesn't elevate npmjs.org to some kind of "holy url" that shall not be changed. |
I believe this also impacts users from countries where npm is blocked and they use proxies? |
I believe this also impacts users from countries where npm is blocked and they use proxies? You can still configure npm with proxy servers etc to bypass this (or use a VPN). |
corepack supports downloading the package managers from a source that is not npm. I think this is a significant security risk for our users and we should only download them from npm (or another 3rd party registry, not just a URL).
The text was updated successfully, but these errors were encountered: