aws-cli
aws-cli copied to clipboard
Feature Request: Hosting GPG Key
Describe the solution you'd like
AWS has one GPG key available to download here: https://d1.awsstatic.com/security-center/aws-security-20190115-8490A11E.1746bab76c79738a45967dca72b2e5c5202aa6ad.asc
More info described here: https://aws.amazon.com/security/aws-pgp-public-key/
Unfortunately, AWS CLI uses a separate GPG key for verifying an installation: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html#v2-install-linux-validate
This GPG key don't have an URL that can be downloaded easily with scripts, forcing you to copy/paste the key and find a way to distribute it before running your scripts.
It would be nice that this GPG key is hosted somewhere curl friendly, with the naming of:
awscli-exe-linux-x86_64.zip.asc
Another option could be storing the GPG key in a keyserver, allowing to do:
gpg --keyserver ${KEY_SERVER} --receive-keys ${KEY}
This would help a lot for CI/CD, scripts, automation, even VSCode DevContainers setup.
Thanks for the feature request, @sigonzal3!
@kdaily Could this issue receive a bit more attention and love please? Here is why this is quite important.
- Following the closed discussion here, developers/dev(sec)ops have a limited choice to install the AWS cli. See #4947
- In automated processes like creating a container image that rely on the cli and other tools, it nearly impossible to parse a HTML page to extract the PGP signing key in order to verify the signature. This obviously break automated processes.
It would be nice to :
- Have the key hosted on a keyserver
- Have the key hosted alongside the releases. Something like
https://awscli.amazonaws.com/gpg-signing-key-$AWSCLI_VERSION.asc
+1 on this. This would also help with providing updated keys when old ones expire. For example, at time of writing, the docs pages here and here have old keys that expired 2023-09-17, while the doc page here has the latest (that I could find) which expires 2024-07-26. Having a centrally-hosted place for this key would keep the docs DRY and up-to-date.
+1 on this. This would also help with providing updated keys when old ones expire. For example, at time of writing, the docs pages here and here have old keys that expired 2023-09-17, while the doc page here has the latest (that I could find) which expires 2024-07-26. Having a centrally-hosted place for this key would keep the docs DRY and up-to-date.
And now we are at 2024-07-28 (as of the time of writing), this key has now also expired, but is still listed.
2025 and still no action on this...
How is this not a thing?