Use release-keys from git

[johanneswuerbach]

Description

Use release keys from git instead of maintaining a hardcoded list fetched from a key servers, related to #1500

Motivation and Context

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Others (non of above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[nschonni]

Seems like the clear for the CLI should be called at the end with the other cleanup and remove the repo at that point

[BenjD90]

and maybe remove bash (apk del bash) at the end ?

[nschonni]

Could probably skip the git dep, and maybe curl https://github.com/nodejs/release-keys/archive/refs/heads/master.zip to keep a smaller footprint than all the repo history (even though it's small now)

[SimenB]

hardcoding master seems inconvenient, what about just git clone --depth 1?

[johanneswuerbach]

I found it somehow odd to not pin the commit here or validate the downloaded artefact afterwards, maybe it would make sense to create a releases in https://github.com/nodejs/release-keys? While those are only keys, we are executing a random bash script here.

[SimenB]

this change should not be included in this PR

[johanneswuerbach]

Is there a way to re-generate those files from the template without updating the version? I tested ./update.sh -b, but that just fails.

[SimenB]

I'd just revert the changes manually, I don't think our script supports "generate from template, but keep current version"

[nschonni]

Thanks @johanneswuerbach ! I'm going to close this from the comments by the Docker Official images folks that this approach isn't what they're looking for upstream. I've opened #1510 to just try a new keyserver address instead