Skip to content

Release signing keys may be poisoned聽#29531

Description

@canterberry

馃挕 Initially reported in this comment, but I felt it warranted an issue of its own given the age of the issue on which it is attached.

This is not an issue with Node.js itself, but rather with the manner in which the release team's keys are currently distributed.

Impact

Automated installations of Node.js binaries which depend upon the documented method of verifying release signatures are no longer functional. No suitable alternatives currently exist for obtaining public keys of the Node.js release team.

Any tools which continue to rely on the SKS keyserver network may be rendered unusable by certificates poisoned via CVE-2019-13050.

Bottom Line

The SKS keyserver network is no longer a viable option for distributing release keys.

Details

With the recent and unmitigated death of the SKS keyserver network (in CVE-2019-13050), the documented method of obtaining the PGP public keys of the release team is no longer viable, and in fact may have dire consequences to an OpenPGP installation. A different method of distributing release keys, or even of signing and verifying the release package itself, is necessary.

Proposed Solution

For minimal impact, my recommendation would be to place the public keys or authorized releasers within this repo, under a /keys directory, in a manner similar to that of signed RubyGems (except instead of X.509 certificates in a certs/ directory, we'd be talking about ASCII-armored PGP certificates in a keys/ directory), and update the README with instructions on how to import those keys into the OpenGPG keychain from the repo instead of from the SKS keyserver network.

Alternatively, or in addition to the above, publishing these keys to nodejs.org may also provide a second factor to build assurance of the keys' integrity.

馃挕 Especially paranoid users may want to seek additional verification from unaffiliated yet equally trusted soruces by fetching and comparing keys from those sources as well.

Activity

  1. canterberry commented on Sep 12, 2019

    @canterberry
    Author

    鈽濓笍 I volunteer to implement the proposed solution above, but will need copies of the release team's public keys in order to do so.

  2. canterberry commented on Sep 12, 2019

    @canterberry
    Author

    Discussion on this issue continues in nodejs/build#1913 -- keeping this issue around for reference, since this repo's README.md will need an update and it would be helpful to have an issue for the PR to reference.

  3. added
    releaseIssues and PRs related to Node.js releases.
    on Dec 26, 2020
  4. avivkeller commented on May 24, 2024

    @avivkeller
    Member

    Hi! This issue hasn't seen any activity in a while, and it looks like the issue was resolved, is it okay to close this issue?

  5. canterberry commented on May 30, 2024

    @canterberry
    Author

    The "bottom line" of this issue has been resolved -- SKS keyservers are no longer part of the release verification documentation.

    However, the class of vulnerability intended to be mitigated by the nodejs/release-keys repo remains -- the documented flow for release verification depends on an third-party service (i.e: a service not maintained or influenced by the Node.js release team).

    The nodejs/release-keys repo is not cross-referenced in https://github.com/nodejs/node?tab=readme-ov-file#verifying-binaries -- instead, references to SKS keyservers have simply been replaced with keys.openpgp.org.

    Thus, while the nodejs/release-keys repo does exist and is actively maintained, since it is not mentioned in the Node.js README for release verification, most users will likely not find it.

  6. avivkeller commented on May 30, 2024

    @avivkeller
    Member

    Got it. Feel free to open a PR to add the missing docs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    releaseIssues and PRs related to Node.js releases.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions