-
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
Feature request: instructions on how to determine the hash for the packageManager
field in package.json
#231
Comments
A couple of options:
|
How about adding something like “corepack --save yarn@3.2.1” that writes to the package.json? |
I think the official guidance is: package managers should provide this information, as there are no reliable ways of doing it yourself without trusting HTTPS + that the remote server wasn't hijacked, which kinda defeats the purpose of having a hash.
I like the idea, it's of course not great from a security perspective but would be very practical – and folks who needs the extra security can still use a manual workflow. |
In the case of Yarn we have It'd be convenient to have something like this in Corepack (especially for package managers that don't have similar commands), but I'm a little worried that it would make the Yarn UX more confusing for Yarn users: should they use the Corepack command, or the Yarn one? What happens if a tutorial uses the Corepack command, but a user somehow doesn't have Corepack installed? Ideally, I think I'd prefer if users didn't have to deal with Corepack at all once they have enabled it, so that their workflows stay exactly the same with / without. |
I already have to interact with corepack I think a new command for |
Would love this as well. I would like to place a SHA here, but don't want to burden future maintainers of my repo with having to figure out how to generate that SHA when they go to update the package manager... Either a command to provide it or just updating the docs would be helpful here. |
done with version 1.22.19 of Yarn: ```Shell yarn --version ``` ``` 1.22.19 ``` ```Shell yarn set version -- 3.6.0 ``` ``` warning package.json: No license field ➤ YN0000: Retrieving https://repo.yarnpkg.com/3.6.0/packages/yarnpkg-cli/bin/yarn.js ➤ YN0000: Saving the new release in .yarn/releases/yarn-3.6.0.cjs ➤ YN0000: Done in 0s 668ms ``` afterwards, Yarn honours the setting `yarnPath` in its configuration file `.yarnrc.yml`: ```Shell yarn --version ``` ``` 3.6.0 ``` Yarn does not support the extension `*.yaml` for its configuration file. The setting `packageManager` in `package.json` admits a checksum. In this case, a checksum is not necessary, because Yarn is committed to the repository. nodejs/corepack#231
[Version 16.20.0 of Node.js][Node.js changelog 16.20.0], released on 2023-03-29, ships with version 0.17.0 of [Corepack][Node.js 16 Corepack]; see the corresponding [pull request][GitHub repository nodejs/node PR 46842]. 3.6.0 is the latest version of Yarn at this time. As stated in the [README][Node.js Corepack 0.17.0 README], a checksum should be specified: > The hash is optional but strongly recommended as a security practice. Version 0.17.0 of [Corepack][Node.js 16 Corepack] uses the function `createHash` of the [Node.js module `node:crypto`][Node.js 16 node:crypto]; see https://github.com/nodejs/corepack/blob/v0.17.0/sources/corepackUtils.ts#L138-L140. The hash/hashing algorithms that function supports "[…] is dependent on the available algorithms supported by the version of OpenSSL on the platform". I chose [SHA-512][SHA-2] because it strikes the best balance between safety/security and availability, as far as I know. [GitHub repository nodejs/corepack issue 231][] ```Shell curl -- https://repo.yarnpkg.com/3.6.0/packages/yarnpkg-cli/bin/yarn.js | sha512sum ``` ``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2175k 0 2175k 0 0 3902k 0 --:--:-- --:--:-- --:--:-- 3899k 418e45c2268c4d6b69a28f3939084b5853d5f392c43c0b5588bd1995a96e328414ae4b7777a8980c64bad4328c52586ff879b289f98ae65372a55fa4d0ff70dd - ``` after setting `packageManager` in `package.json` with that checksum: ```Shell corepack yarn --version ``` ``` 3.6.0 ``` There's no difference between calling `corepack yarn` and calling the `yarn` shim installed by `corepack enable`; both are the same: ```JavaScript require('./corepack').runMain(['yarn', ...process.argv.slice(2)]); ``` the .js file is not committed and `yarnPath` is not set: yarnpkg/berry#4063 (comment) > Updating the binary in the repo, is temporary, until Corepack gets > available in all LTS releases. I think for Yarn 4 we'll consider only > updating the package.json. indeed, https://github.com/yarnpkg/berry/blob/master/CHANGELOG.md#major-changes > `yarn set version` will now skip generating the `yarnPath` > configuration on new projects if it detects you're using > [Corepack][Node.js Corepack] [GitHub repository nodejs/corepack issue 231]: nodejs/corepack#231 [GitHub repository nodejs/node PR 46842]: nodejs/node#46842 [GitHub repository yarnpkg/berry issue 4063]: yarnpkg/berry#4063 [Node.js changelog 16.20.0]: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.20.0 [Node.js Corepack]: https://nodejs.org/api/corepack.html [Node.js Corepack 0.17.0 README]: https://github.com/nodejs/corepack/blob/v0.17.0/README.md [Node.js 16 Corepack]: https://nodejs.org/docs/latest-v16.x/api/corepack.html [Node.js 16 node:crypto]: https://nodejs.org/docs/latest-v16.x/api/crypto.html [SHA-2]: https://en.wikipedia.org/wiki/SHA-2
[Version 16.20.0 of Node.js][Node.js changelog 16.20.0], released on 2023-03-29, ships with version 0.17.0 of [Corepack][Node.js 16 Corepack]; see the corresponding [pull request][GitHub repository nodejs/node PR 46842]. 3.6.0 is the latest version of Yarn at this time. As stated in the [README][Node.js Corepack 0.17.0 README], a checksum should be specified: > The hash is optional but strongly recommended as a security practice. Version 0.17.0 of [Corepack][Node.js 16 Corepack] uses the function `createHash` of the [Node.js module `node:crypto`][Node.js 16 node:crypto]; see https://github.com/nodejs/corepack/blob/v0.17.0/sources/corepackUtils.ts#L138-L140. The hash/hashing algorithms that function supports "[…] is dependent on the available algorithms supported by the version of OpenSSL on the platform". I chose [SHA-512][SHA-2] because it strikes the best balance between safety/security and availability, as far as I know. [GitHub repository nodejs/corepack issue 231][] ```Shell curl -- https://repo.yarnpkg.com/3.6.0/packages/yarnpkg-cli/bin/yarn.js | sha512sum ``` ``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2175k 0 2175k 0 0 3902k 0 --:--:-- --:--:-- --:--:-- 3899k 418e45c2268c4d6b69a28f3939084b5853d5f392c43c0b5588bd1995a96e328414ae4b7777a8980c64bad4328c52586ff879b289f98ae65372a55fa4d0ff70dd - ``` after setting `packageManager` in `package.json` with that checksum: ```Shell corepack yarn --version ``` ``` 3.6.0 ``` There's no difference between calling `corepack yarn` and calling the `yarn` shim installed by `corepack enable`; both are the same: ```JavaScript require('./corepack').runMain(['yarn', ...process.argv.slice(2)]); ``` the .js file is not committed and `yarnPath` is not set: yarnpkg/berry#4063 (comment) > Updating the binary in the repo, is temporary, until Corepack gets > available in all LTS releases. I think for Yarn 4 we'll consider only > updating the package.json. indeed, https://github.com/yarnpkg/berry/blob/master/CHANGELOG.md#major-changes > `yarn set version` will now skip generating the `yarnPath` > configuration on new projects if it detects you're using > [Corepack][Node.js Corepack] [GitHub repository nodejs/corepack issue 231]: nodejs/corepack#231 [GitHub repository nodejs/node PR 46842]: nodejs/node#46842 [GitHub repository yarnpkg/berry issue 4063]: yarnpkg/berry#4063 [Node.js changelog 16.20.0]: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.20.0 [Node.js Corepack]: https://nodejs.org/api/corepack.html [Node.js Corepack 0.17.0 README]: https://github.com/nodejs/corepack/blob/v0.17.0/README.md [Node.js 16 Corepack]: https://nodejs.org/docs/latest-v16.x/api/corepack.html [Node.js 16 node:crypto]: https://nodejs.org/docs/latest-v16.x/api/crypto.html [SHA-2]: https://en.wikipedia.org/wiki/SHA-2
[Version 16.20.0 of Node.js][Node.js changelog 16.20.0], released on 2023-03-29, ships with version 0.17.0 of [Corepack][Node.js 16 Corepack]; see the corresponding [pull request][GitHub repository nodejs/node PR 46842]. 3.6.0 is the latest version of Yarn at this time. As stated in the [README][Node.js Corepack 0.17.0 README], a checksum should be specified: > The hash is optional but strongly recommended as a security practice. Version 0.17.0 of [Corepack][Node.js 16 Corepack] uses the function `createHash` of the [Node.js module `node:crypto`][Node.js 16 node:crypto]; see https://github.com/nodejs/corepack/blob/v0.17.0/sources/corepackUtils.ts#L138-L140. The hash/hashing algorithms that function supports "[…] is dependent on the available algorithms supported by the version of OpenSSL on the platform". I chose [SHA-512][SHA-2] because it strikes the best balance between safety/security and availability, as far as I know. [GitHub repository nodejs/corepack issue 231][] ```Shell curl -- https://repo.yarnpkg.com/3.6.0/packages/yarnpkg-cli/bin/yarn.js | sha512sum ``` ``` % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2175k 0 2175k 0 0 3902k 0 --:--:-- --:--:-- --:--:-- 3899k 418e45c2268c4d6b69a28f3939084b5853d5f392c43c0b5588bd1995a96e328414ae4b7777a8980c64bad4328c52586ff879b289f98ae65372a55fa4d0ff70dd - ``` after setting `packageManager` in `package.json` with that checksum: ```Shell corepack yarn --version ``` ``` 3.6.0 ``` There's no difference between calling `corepack yarn` and calling the `yarn` shim installed by `corepack enable`; both are the same: ```JavaScript require('./corepack').runMain(['yarn', ...process.argv.slice(2)]); ``` the .js file is not committed and `yarnPath` is not set: yarnpkg/berry#4063 (comment) > Updating the binary in the repo, is temporary, until Corepack gets > available in all LTS releases. I think for Yarn 4 we'll consider only > updating the package.json. indeed, https://github.com/yarnpkg/berry/blob/master/CHANGELOG.md#major-changes > `yarn set version` will now skip generating the `yarnPath` > configuration on new projects if it detects you're using > [Corepack][Node.js Corepack] [GitHub repository nodejs/corepack issue 231]: nodejs/corepack#231 [GitHub repository nodejs/node PR 46842]: nodejs/node#46842 [GitHub repository yarnpkg/berry issue 4063]: yarnpkg/berry#4063 [Node.js changelog 16.20.0]: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.20.0 [Node.js Corepack]: https://nodejs.org/api/corepack.html [Node.js Corepack 0.17.0 README]: https://github.com/nodejs/corepack/blob/v0.17.0/README.md [Node.js 16 Corepack]: https://nodejs.org/docs/latest-v16.x/api/corepack.html [Node.js 16 node:crypto]: https://nodejs.org/docs/latest-v16.x/api/crypto.html [SHA-2]: https://en.wikipedia.org/wiki/SHA-2
Addressed by #291 (which adds |
The README.md states that "the hash is optional but strongly recommended as a security practice", but provides no guidance on how to determine an acceptable hash.
I can see hashes in config.json—and I can also see a workflow that updates them automatically—but it would be good to be able to easily determine the shasum for the version you're currently using.
The text was updated successfully, but these errors were encountered: