Sops: Releases should include hashes or signatures
Feature Request
Currently the releases are only binary files downloaded over TLS. It would be great to have a GPG .sig or a link to the SHA2 hashes of the binaries to verify authentication after downloading the release.
User Story
As a security engineer, I would like an additional way to cryptographically verify a shipped binary has not been tampered with.
b-meson
All 6 comments
The releases are generated by a CI environment, so we'd have to trust it to store a crypto key. This is probably fine, but not as good as holding the key in a secure location.
An alternative, if you want that level of security, would be to build sops from git and verify my PGP signature on the release tag.
jvehent
on 24 Apr 2018
I think it is fine to publish packages using CI. I am wondering if you can at minimum add a sha256 sum for the packages.
_Ideally_ these packages would be published and signed using an offline (airgapped) GPG key but I understand that complicates the packaging / release workflow.
b-meson
on 16 May 2018
I'm not sure what the sha256 buys you? I can't think of a scenario where someone can tamper with the binary but not with the sha.
autrilla
on 16 May 2018
@autrilla oh yes you're absolutely correct. So I am not sure how to proceed unless there is a way to support reproduceable builds?
b-meson
on 23 May 2018
Publishing sha256 hashes would help to at least validate that all downloads of the same sops version result in the same binary. I could put those hashes in an ansible playbook for example, and run that playbook at a later time and still be sure that I'm getting the exact same thing. It won't validate that the binary is untampered, but it will at least validate that it is unchanged.
Currently I just download it once and get the hash that way, but it would be more convenient to have them presented on the download page for each release.
rnijveld
on 18 Sep 2019
An alternative, if you want that level of security, would be to build sops from git and verify my PGP signature on the release tag.
@jvehent where do we find the public keys used to sign the release tags? E.g. git verify-tag v3.6.1 tells me that the tag is signed with key E120C2F633D6B97777E0050A591A358DF842D281, but this key isn't available on keys.openpgp.org:
$ gpg --search E120C2F633D6B97777E0050A591A358DF842D281
gpg: data source: https://keys.openpgp.org:443
gpg: key "E120C2F633D6B97777E0050A591A358DF842D281" not found on keyserver
gpg: keyserver search failed: Not found
(It doesn't appear to be available in the legacy keyservers either)
larsks
on 1 Oct 2020
Related issues
mrgleeco
路
7Comments
mccutchen
路
3Comments
benjefferies
路
6Comments
Mic92
路
4Comments
conorsch
路
5Comments
Most helpful comment
Publishing sha256 hashes would help to at least validate that all downloads of the same sops version result in the same binary. I could put those hashes in an ansible playbook for example, and run that playbook at a later time and still be sure that I'm getting the exact same thing. It won't validate that the binary is untampered, but it will at least validate that it is unchanged.
Currently I just download it once and get the hash that way, but it would be more convenient to have them presented on the download page for each release.