chore: pull Releaser keys from keyring instead of README

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.

[nschonni]

Description

Doesn't replace the way the keys are embedded in the Dockerfiles, but use the newer keyring file to read the fingerprints.

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)
• Other (none of the 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.

[aduh95]

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

[nschonni]

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

[aduh95]

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

[nschonni]

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth

[MikeMcC399]

We need to move forward with this enhancement PR.

Executing the existing script ./update-keys.sh in the main branch produces no change.

It needs the changes in this PR, which pull from https://github.com/nodejs/release-keys/blob/main/gpg-only-active-keys/pubring.kbx, to get up-to-date results.

Branch	Result
main	no change
nschonni:kbk-script	removes 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600

The key 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 belongs to @targos who has stepped down from the Releasers role. This key removal was implemented in nodejs/release-keys#58 for the keyring, however no change was made in the list on https://github.com/nodejs/node#release-keys.

docker-node should stop including the 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 key when any Dockerfile is updated for a new release. This is however only possible if the synchronization is up-to-date.