Implements signed releases

[arcanis]

With those changes, the following files will be generated by the release process; I can also see to make an alias on latest to quickly find the most recent public key:

• https://repo.yarnpkg.com/VERSION/packages/yarnpkg-cli/bin/yarn.js - The actual file.

• https://repo.yarnpkg.com/VERSION/packages/yarnpkg-cli/bin/yarn.js.sign - The signature for the file.

• https://repo.yarnpkg.com/VERSION/packages/yarnpkg-cli/bin/yarn.pem - The public key used for signing the file. Should be the same from one release to another, mostly here for convenience (it's easy to detect when the key changes).

I used the following commands to generate the private and public keys I added to the repository:

openssl ecparam -genkey -name secp384r1 -noout -out yarn.key
openssl ec -in yarn.key -pubout -out yarn.pem

[arcanis]

cc @merceyz @aduh95 do you see an issue with that plan?

[aduh95]

If the private key gets compromised for whatever reason, you probably want to keep an option to provide more than one signature. Maybe an option would be to provide yarn.js.[key id].sign or [key id]/yarn.js.sign. I would put the public key(s) in a JSON file global to the whole registry, so if/when a key is compromised, or is lost, you can mark it as expired.

[aduh95]

I wouldn't store the public key as secret, it's a better idea to derive it from the private key – or store it in clear.

[arcanis]

I kept it as a secret to make clear both values were linked and needed to be updated should we need to change it (rather than hardcode it in a separate place), but true, it could be derived within the script itself 🤔

[arcanis]

If the private key gets compromised for whatever reason, you probably want to keep an option to provide more than one signature. Maybe an option would be to provide yarn.js.[key id].sign or [key id]/yarn.js.sign. I would put the public key(s) in a JSON file global to the whole registry, so if/when a key is compromised, or is lost, you can mark it as expired.

Do you mean that in case of compromission we'd reissue new signatures for all files with the new key? Is it a common practice?

[aduh95]

I don't know if it's common practice, but what I would do would be to reissue new signatures for supported versions – though I suppose making a new patch release for all supported branches would be the same result.

In any case, IMO having a global registry for public keys would be much much better than "check the previous release key to see if it's the same". And once you have a global registry of private key, it's easy enough to use a naming convention that would allow providing multiple signatures, even though it might never be necessary in practice.