Improve security of downloading the binary by checking the fingerprint

[arthurzenika]

Is your feature request related to a problem? Please describe.

As described on the asdf issues asdf-vm/asdf#1320 , it would be safer if the plugins would check a fingerprint for the binaries it downloads. Additionnally (for the specific case of awscli) gpg checking could be done.

The documentation

(for example for linux) gives a number of commands to check the downloaded binary https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

A quick search doesn't show me any sha256 fingerprints of the zip file, maybe you know where to find this.

Describe the solution you'd like

Add some checks in the bash scripts.

Describe alternatives you've considered

Have another plugin / program that checks after asdf has downloaded and installed things, but this is not ideal.

Additional context

This can be an important security risk for users how have corporate certificates installed on their work stations and thus https/ssl cannot but trusted.

[MetricMike]

Thanks for submitting this - it's definitely a feature we should add and I hope to get to it soon.

It's a little annoying that AWS only provides GPG/RSA signatures and the public key expires in September, but I don't think that's a big deal? When aws/aws-cli#7908 is resolved, I think verifying the sha256/512 checksum would be sufficient for most cases but you mentioned it as a complement so I'm curious if there's a specific reason why GPG checks might be superior here? I only know enough about cryptography to get myself in trouble.

I expect to follow along with how asdf-nodejs did it in asdf-vm/asdf-nodejs#25 and use an environment variable to opt-in to signature checking, but I'll note that asdf-nodejs ran into a number of issues and eventually dropped it in asdf-vm/asdf-nodejs#272 although their decision was easier because they could defer to node-build's built-in signature verification.

[arthurzenika]

Thanks for taking a look at this issue !

GPG signatures are complementary (and sometimes considered better) to sha512 checksum verification because in some situations one cannot trust SSL certificates[1] [2] and so an attacker can modify the build of the software and the sha256 fingerprints.

GPG can have a web-of-trust mechanism and so is trickier to attack. This is the reason why apt repositories in debian have been for years served with http and not https (see explanation in https://unix.stackexchange.com/questions/90227/why-is-there-no-https-transport-for-debian-apt-tool ). In the case of debian repos using https protects metadata info about what is being downloaded, but not the provenance of the software.

Having the sha256 or gpg keys in git with signed git commits can also be a harder to attack model.

You can also check how terraform deployed using asdf is implemented with a gpg check : https://github.com/asdf-community/asdf-hashicorp/blob/master/bin/install

[1] if you follow a bit the bad Certificates Authorities (cf https://sslmate.com/resources/certificate_authority_failures ) that are shipped in a lot of places, there is good reason not to trust them
[2] in some corporate settings some certificates for man-in-the-middle/inspecting proxies are inserted in various places then SSL certificates cannot be trusted either