chore: use release-keys keyring for gpg fingerprints#2459
Conversation
|
@aduh95 this doesn't replace your PR, but was what I was trying to explain in the thread. If your approach doesn't get accepted by the Docker Hub people, this at least streamlines the Releaser onboarding and revoking of old keys process. |
|
I don't really see the point, this does not change the fact that building our docker images depend on the external key servers. I guess it does slightly reduce the maintenance burden because there are fewer files, but those files are used by external projects (see https://github.com/search?q=nodejs%2Fdocker-node+keys%2Fnode.keys&type=code), so it would be breaking for the ecosystem without addressing the concern I was trying to address in #2415. TL;DR I don't think we should merge this. |
There was a problem hiding this comment.
I previously only reviewed whether the workflow achieved its described goals. I would like to add some process and governance considerations now:
The PR conflicts with the process defined in the Release / GOVERNANCE.md which specifies:
Adding new releasers
- Open a PR in nodejs/docker-node to add their GPG key to node.keys.
Offboarding releasers
- Open a PR in nodejs/docker-node to remove their GPG key from node.keys.
The PR states as goal:
... removes the need for PRs here when onboarding new Releasers.
This however removes any opportunity for a review and approval cycle in this repo, since no PR is created. That would appear to be a governance issue.
I suggest to re-examine goals and constraints for Node.js key update and management in this repo.
The needs of the Node.js Releasers Team as well as those of the external Docker Official Images team concerning alternate key handling concepts need to be considered.
See also requirements for Docker Official Images.
In the Security section of their README it gives examples with differing levels of security. In all examples with acceptable levels of security there is either a key or a checksum embedded in the Dockerfile.
Description
This doesn't change to go away from the keyservers like in #2415, but points to the upstream source, and removes the need for PRs here when onboarding new Releasers.
Motivation and Context
Testing Details
Example Output(if appropriate)
Types of changes
Checklist