Verify checksums and GPG key signatures for downloaded binaries

[wata727]

TFLint installed with this action has not been verified for checksums/signatures. This action is typically performed on the GitHub infrastructure, and binaries are distributed under the organization we maintain, so it is unlikely to be affected by supply chain attacks, but it's best practice to do these for security.

[bendrucker]

It would be good to add an input for this (checksum) to compliment version. Verifying a binary downloaded from GitHub releases against a checksum also downloaded from the same release doesn't really secure against a targeted supply chain attack. Anyone able to upload/serve a malicious binary could also replace the checksums. Reasonable to do anyway but minimally protective. For users who pin a specific version, allowing them to specify the checksum would guarantee immutability.

For users who don't pin, in theory we could persist the resolved version and checksum and then error if a future workflow run resolved the same version but a different checksum. @actions/cache could be helpful there.

[wata727]

Thank you for your reply. I think it's a good idea to input a checksum, but it can be a bit annoying for a user.

In my understanding, by hard-coding the public signing key, you can safely verify the checksum even if you get it from the same release. This is the same way as downloading a plugin binary.

However, this also makes other issues, such as key rotation. I opened this issue because I noticed that a plugin was verified but the TFLint binary wasn't verified.

[bendrucker]

I think it's a good idea to input a checksum, but it can be a bit annoying for a user.

Yep, mostly an option for users who want a true immutability guarantee once they pick a version. With that immutability comes decreased convenience. In a corporate environment there might be some interest in immutability. I've seen companies using digests to pull Docker images rather than tags, for example.

And yes, hardcoding the signing key helps, particularly for any kind of MITM. For an attack on GitHub itself there's a similar convenience/security trade off. Multiple releasers probably means putting a signing key in CI, which means compromising GitHub or the org/repo allows malicious binaries to be signed.