nodejs
Start adding .asc signature files for tar files to validate signature
What is the problem this feature will solve?
Right now, node uses SHA256 checksums to verify published artifacts like tars. Signatures offer stronger security. Some packages already do this like Yarn: https://github.com/yarnpkg/yarn/releases/tag/v1.22.17
What is the feature you are proposing to solve the problem?
Start adding .asc signature files in index (e.g. https://nodejs.org/download/release/v16.20.2/)
What alternatives have you considered?
No response
We already sign the SHASUMS256.txt file. e.g. https://nodejs.org/download/release/v16.20.2/SHASUMS256.txt.asc
Im using gradle to verify the dependencies and downloading the SHASUM256.txt.asc and placing it with the tar artifacts did not work. I then renamed the file to node-16.20.2-darwin-arm64.tar.gz.asc and kept only the PGP Signature, and added the full fingerprint id of the key to the verifcations-metadata.xml file but Gradle still failed to verify the dependency.
I also get the following when I run gpg:
gpg --verify node-16.20.2-darwin-arm64.tar.gz.asc
gpg: assuming signed data in '../../prebuilts/androidx/external/org/nodejs/node/16.20.2/node-16.20.2-darwin-arm64.tar.gz'
gpg: Signature made Wed 9 Aug 17:40:10 2023 BST
gpg: using RSA key 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4
gpg: BAD signature from "RafaelGSS <[email protected]>" [expired]
I also get the following when I run gpg:
gpg --verify node-16.20.2-darwin-arm64.tar.gz.asc gpg: assuming signed data in '../../prebuilts/androidx/external/org/nodejs/node/16.20.2/node-16.20.2-darwin-arm64.tar.gz' gpg: Signature made Wed 9 Aug 17:40:10 2023 BST gpg: using RSA key 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4 gpg: BAD signature from "RafaelGSS <[email protected]>" [expired]
@RafaelGSS was going to reupload his key (with extended expiry). However note that that signing key had not expired at the time Node.js 16.20.2 was released (August 2023) and signed.
The checksum file is nice for manual validation, however for an automated signature checking with a tool like Gradle it does not help at all (or I haven't found a way yet). It'd be great if we can have per platform file armored files to enable automated signature verification when downloading the artifact
@RafaelGSS reviving this thread, I see the key was updated, but is it not possible to publish an .asc file for each artifact released? For example, node-v22.0.0-darwin-arm64.tar.gz has node-v22.0.0-darwin-arm64.tar.gz.asc, etc.
the end result would look like this: https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-coroutines-core/1.8.1/
Maybe? cc: @richardlau
However, if we do that, we'll need to do it eventually after each 2 years (the usual expire date for keys - at least mine)
It looks like the problem resurfaced for v23.0.0:
gpg: assuming signed data in 'SHASUMS256.txt' gpg: Signature made 10/16/24 16:07:24 Romance Daylight Time gpg: using RSA key 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4 gpg: Good signature from "RafaelGSS <[email protected]>" [expired] gpg: Note: This key has expired!
@richardlau what do you think of publishing an .asc file for each artifact released?
It's not practical with the current model of releasers signing the releases with their own key. The scripted process downloads the SHASUM files to the releaser's machine, signs and then uploads the signed artifacts (i.e. the SHASUM .asc and .sig files). To do this for all artifacts would require the releaser to download 1.5 GB per release.
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the https://github.com/nodejs/node/labels/never-stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.