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 request: instructions on how to determine the hash for the packageManager field in package.json #231

Closed
bennettp123 opened this issue Jan 15, 2023 · 7 comments

Comments

@bennettp123
Copy link

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.

@bennettp123
Copy link
Author

A couple of options:

  1. npm show <npm|yarn|pnpm>@<version> dist.shasum will print the SHA-1 checksum. Or you could use the curl | jq commands in the workflow
  2. something like corepack show or corepack info that provides the necessary info (maybe even sha-224/sha-256/sha-512 instead of sha-1)

@styfle
Copy link
Member

styfle commented Jan 16, 2023

How about adding something like “corepack --save yarn@3.2.1” that writes to the package.json?

@aduh95
Copy link
Contributor

aduh95 commented Jan 16, 2023

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 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.
That being said, the added hash still benefits other users and yourself if you ever clean up your cache, the relative security risk is worth taking. In that case, the unofficial guidance is to set a dummy hash (e.g. "packageManager": "yarn@3.0.0+sha224.deadbeef"), run Corepack, get the actual hash from the error message, and voilà.

How about adding something like “corepack --save yarn@3.2.1” that writes to the package.json?

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.

@arcanis
Copy link
Contributor

arcanis commented Jan 16, 2023

How about adding something like “corepack --save yarn@3.2.1” that writes to the package.json?

In the case of Yarn we have yarn set version. It doesn't currently save the hash, but I'd like it to do that.

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.

@styfle
Copy link
Member

styfle commented Jan 17, 2023

I'd prefer if users didn't have to deal with Corepack at all once they have enabled it

I already have to interact with corepack activate to install a global version for projects that don’t have packageManager defined.

I think a new command for corepack set pkg@version would be perfect 👍

@Techn1x
Copy link

Techn1x commented Jun 5, 2023

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.

kalrish added a commit to kalrish/AWS-organization-bootstrap that referenced this issue Jun 26, 2023
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
kalrish added a commit to kalrish/AWS-organization-bootstrap that referenced this issue Jun 27, 2023
[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
kalrish added a commit to kalrish/AWS-organization-bootstrap that referenced this issue Jun 28, 2023
[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
kalrish added a commit to kalrish/AWS-organization-bootstrap that referenced this issue Jun 28, 2023
[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
@aduh95
Copy link
Contributor

aduh95 commented Feb 21, 2024

Addressed by #291 (which adds corepack use … and corepack up commands)

@aduh95 aduh95 closed this as completed Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants