-
Notifications
You must be signed in to change notification settings - Fork 10.1k
Switch from golang.org/x/crypto/openpgp to github.com/ProtonMail/go-crypto #32056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This replaces `golang.org/x/crypto/openpgp` with `github.com/ProtonMail/go-crypto`, since the former has been deprecated (see golang/go#44226), and the latter is a (mostly) backwards-compatible fork. I'm not a cryptographer and haven't audited `github.com/ProtonMail/go-crypto` for correctness, but it's already used in several other Hashicorp projects (https://github.com/search?q=org%3Ahashicorp+go-crypto&type=code), so I assume it's been reviewed and approved by Hashicorp. One improvement this brings is support for ECC keys, which has been requested before: hashicorp/terraform-docs-common#106 There is one change in the fork that's arguably backwards-incompatible: `CheckDetachedSignature()` will now throw an error if the key used to sign the signature is expired. This caused the `TestNewSignatureAuthentication_success` test to fail, since it was signed with an expired subkey. You can verify this on the command line with these commands: $ echo $'fea4227271ebf7d9e2b61b89ce2328c7262acd9fd190e1fd6d15a591abfa848e terraform-provider-null_3.1.0_darwin_amd64.zip\n9ebf4d9704faba06b3ec7242c773c0fbfe12d62db7d00356d4f55385fc69bfb2 terraform-provider-null_3.1.0_darwin_arm64.zip\na6576c81adc70326e4e1c999c04ad9ca37113a6e925aefab4765e5a5198efa7e terraform-provider-null_3.1.0_freebsd_386.zip\n5f9200bf708913621d0f6514179d89700e9aa3097c77dac730e8ba6e5901d521 terraform-provider-null_3.1.0_freebsd_amd64.zip\nfc39cc1fe71234a0b0369d5c5c7f876c71b956d23d7d6f518289737a001ba69b terraform-provider-null_3.1.0_freebsd_arm.zip\nc797744d08a5307d50210e0454f91ca4d1c7621c68740441cf4579390452321d terraform-provider-null_3.1.0_linux_386.zip\n53e30545ff8926a8e30ad30648991ca8b93b6fa496272cd23b26763c8ee84515 terraform-provider-null_3.1.0_linux_amd64.zip\ncecb6a304046df34c11229f20a80b24b1603960b794d68361a67c5efe58e62b8 terraform-provider-null_3.1.0_linux_arm64.zip\ne1371aa1e502000d9974cfaff5be4cfa02f47b17400005a16f14d2ef30dc2a70 terraform-provider-null_3.1.0_linux_arm.zip\na8a42d13346347aff6c63a37cda9b2c6aa5cc384a55b2fe6d6adfa390e609c53 terraform-provider-null_3.1.0_windows_386.zip\n02a1675fd8de126a00460942aaae242e65ca3380b5bb192e8773ef3da9073fd2 terraform-provider-null_3.1.0_windows_amd64.zip' > SHA256SUMS $ echo -n 'wsFcBAABCAAQBQJgga+GCRCwtEEJdoW2dgAAo0YQAAW911BGDr2WHLo5NwcZenwHyxL5DX9g+4BknKbc/WxRC1hD8Afi3eygZk1yR6eT4Gp2HyNOwCjGL1PTONBumMfj9udIeuX8onrJMMvjFHh+bORGxBi4FKr4V3b2ZV1IYOjWMEyyTGRDvwSCdxBkp3apH3s2xZLmRoAj84JZ4KaxGF7hlT0j4IkNyQKd2T5cCByN9DV80+x+HtzaOieFwJL97iyGj6aznXfKfslK6S4oIrVTwyLTrQbxSxA0LsdUjRPHnJamL3sFOG77qUEUoXG3r61yi5vWV4P5gCH/+C+VkfGHqaB1s0jHYLxoTEXtwthe66MydDBPe2Hd0J12u9ppOIeK3leeb4uiixWIirNdpWyjr/LU1KKWPxsDqMGYJ9TexyWkXjEpYmIEiY1Rxar8jrLh+FqVAhxRJajjgSRu5pZj50CNeKmmbyolLhPCmICjYYU/xKPGXSyDFqonVVyMWCSpO+8F38OmwDQHIk5AWyc8hPOAZ+g5N95cfUAzEqlvmNvVHQIU40Y6/Ip2HZzzFCLKQkMP1aDakYHq5w4ZO/ucjhKuoh1HDQMuMnZSu4eo2nMTBzYZnUxwtROrJZF1t103avbmP2QE/GaPvLIQn7o5WMV3ZcPCJ+szzzby7H2e33WIynrY/95ensBxh7mGFbcQ1C59b5o7viwIaaY2' | base64 -d > SHA256SUMS.sig $ gpg --verify SHA256SUMS.sig SHA256SUMS gpg: Signature made Thu Apr 22 10:16:54 2021 PDT gpg: using RSA key B0B441097685B676 gpg: Good signature from "HashiCorp Security (hashicorp.com/security) <[email protected]>" [unknown] gpg: Note: This key has expired! Primary key fingerprint: C874 011F 0AB4 0511 0D02 1055 3436 5D94 72D7 468F Subkey fingerprint: B36C BA91 A2C0 730C 435F C280 B0B4 4109 7685 B676 I removed `TestNewSignatureAuthentication_success` entirely, since I don't have access to the private key to generate a new signature, and it's largely a duplicate of `TestSignatureAuthentication_success`. If someone can give me an updated signature, I'll restore the test.
@alisdair Would you mind reviewing this when you have the chance? Thanks in advance! |
@MasonM this was on the list to triage in October and got missed - human error, my apologies. I will bring this back into the queue and also run this past our security team. Thanks! |
@MasonM, the feedback from the security team is as follows. Although there are no strong objections to using the Do you have a specific use case for the ECC key feature being used with private registries? If so, I can make the "product requirement" case with our product manager to at least put this in the backlog. I noticed the original issue does not have any upvotes, but it is also in a relatively obscure repository and is speaking more towards the HashiCorp Registry, the roadmap of which we do not control. In any case, thanks for this contribution and sparking this conversation. I am happy to keep this alive in the backlog just in case we come around on the need for ECC keys. |
@crw Thanks for getting back to me. The use case I have is integrating with a private Terraform registry at my workplace. The registry uses a custom implementation of the Provider Registry Protocol, similar to https://github.com/outsideris/citizen. The registry protocol requires a GPG signing key, but it doesn't specify it has to be an RSA key. So, when I went to publish a provider to the registry, I used an ECC key, since that's the default in OpenPGP. The registry accepted the ECC key fine, but Terraform gave the following error when trying to use it:
I was able to workaround that by switching to an RSA key, but I think this is a rather confusing gotcha. If the security team doesn't feel this use case is important enough to warrant the additional attack surface of ECC support, then that's perfectly understandable, but I would suggest updating the protocol specification to make it clear that ECC keys are not allowed. In any case, thank you for your time! |
There was a duplicate PR for this entered last week: #33131 The one difference is that instead of removing the |
@crw I know your Security team has already weighed in on this (per #32056 (comment)), but does the additional context provided in #33131 (comment) move the needle at all? We (the Go Security team) would really like to see people moving away from golang.org/x/crypto/openpgp for the good of the ecosystem, but also for selfish reasons as we are forced to carry internal patches for this. |
Hi @rolandshoemaker, thanks for that additional context.
This is also important context. I'll re-raise with the team. |
Hi @MasonM, would you mind pulling the latest from main and resolving the conflicts in go.mod and go.sum. I will then look into merging this! |
Actually looking at the two PRs, I think it's easier for me to create a new one that merges both together as both carry parts that I think are useful. I've raised #33406 with that in mind, and we'll close everything out in there. Thanks for raising this with us, we really do appreciate the support! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
This replaces
golang.org/x/crypto/openpgp
withgithub.com/ProtonMail/go-crypto
, since the former has been deprecated (see golang/go#44226), and the latter is a (mostly) backwards-compatible fork. I'm not a cryptographer and haven't auditedgithub.com/ProtonMail/go-crypto
for correctness, but it's already used in several other HashiCorp projects (https://github.com/search?q=org%3Ahashicorp+go-crypto&type=code), so I assume it's been reviewed and approved by HashiCorp.One improvement this brings is support for ECC keys, which has been requested before (hashicorp/terraform-docs-common#106). I've already verified this works correctly with a private registry.
There is one change in the fork that's arguably backwards-incompatible:
CheckDetachedSignature()
will now return an error if the key used to sign the signature is expired (see ProtonMail/go-crypto#60). This caused theTestNewSignatureAuthentication_success
test to fail, since it was signed with an expired subkey. You can verify this on the command line with these commands, which replicates the test:I removed
TestNewSignatureAuthentication_success
entirely, since I don't have access to the private key to generate a new signature, and it's largely a duplicate ofTestSignatureAuthentication_success
anyway. If someone can give me an updated signature, I'm happy to restore the test.Target Release
1.4.x
Draft CHANGELOG entry
NEW FEATURES