How to verify deb packages before installing ?

[nipil]

Hello

I am (for once !) trying to validate the signatures the deb packages provided in the releases.

It may be well-known but there are no explanations in the release page, and no checksums for the packages.

Could anyone point me in the right direction ?

Nicolas

[felixfontein]

That's a good question. I think the .deb file is not signed, and neither are the .rpm files, so there is no way to validate signatures for them. @getsops/maintainers am I missing something?

I think this is something we have to change. According to https://goreleaser.com/customization/nfpm/ goreleaser supports this, but for that we somehow need a GPG signing key for that which needs to be available to the release automation. That doesn't look like a good idea to me.

Does anyone know how other CNCF projects are doing this?

[er0k]

The linux packages are checksummed in the release workflow. The checksums are base64 encoded and sent to the SLSA generator for provenance. If you decode the subjects, you can find the checksums for the debian packages (these are for the v3.9.0 release):

$ base64 -d subjects.txt | grep deb
c382d0ba899f119840a8cdcc1797f1af9d46e89ec1886bf28de36c0b17867920  sops_3.9.0_arm64.deb
8aee355e3ded54d3421f245dd4ea3352f4849a0c409ce15b51529979256749ca  sops_3.9.0_amd64.deb

You can then find the checksum of the file you downloaded to verify they are the same:

$ sha256sum sops_3.9.0_amd64.deb
8aee355e3ded54d3421f245dd4ea3352f4849a0c409ce15b51529979256749ca  sops_3.9.0_amd64.deb

I'm not sure why these checksums aren't included in the sops-v3.9.0.checksums.txt release artifact 🤷

[duthils]

I just opened a PR to fix the missing packages from the checksums file: #1588

[qg-m-kondratenko]

@duthils I have seen #1588 and #1643. Those are nice, and indeed one of them should be merged. Yet, the issue with the package signatures will not be properly solved by them. It is obvious that sops is trying to steer in direction of cosign. Yet, none of the package formats support it, in turn, bringing us back to the requirement of the traditional pgp for signature. Go releaser has support for such signatures:

signature:
    key_file: "{{ .Env.GPG_KEY_PATH }}"

Yet my concern is if the maintainers are willing to add a traditional gpg key to the project. If so, I would be happy to create a PR adding this functionality.

[qg-m-kondratenko]

@duthils Oh the other hand, it is enough to check the provenance of the rpm/dnf package as it is also signed and contains the file hash. As described in the release under "Verify artifact provenance".

$ slsa-verifier verify-artifact sops-3.9.1-1.x86_64.rpm  \
--provenance-path sops-v3.9.1.intoto.jsonl \
--source-uri github.com/getsops/sops  \
--source-tag v3.9.1
Verified signature against tlog entry index 136745003 at URL: https://rekor.sigstore.dev/api/v1/log/entries/108e9186e8c5677abce97ea806792d60518204b4d269093accc1044c9ec1c3fdbcfc64a5c5210179
Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v2.0.0" at commit d50fda248047372c79368508e1df479970a52cda
Verifying artifact sops-3.9.1-1.x86_64.rpm: PASSED

PASSED: SLSA verification passed

Still, #1588 would be nice to have. And the packages to be signed by native means (pgp) in addition to cosign would be perfect.

Edit: I know, this option has been mentioned by @er0k in this comment, which is also relevant here. The verification code is mentioned to help others who stumble on this issue.

[qg-m-kondratenko]

@felixfontein On the topic of other CNCF projects, there is no single standard among them.

project	sig	packages
envoy	pgp signed sha256sum file	none
helm	pgp signed sha256sum file per binary	none
flux2	cosign sha256sum file	deb (unsigned)
istio	unsigned sha256sum per binary	deb/rpm (unsigned)
jaeger	unsigned sha256sum and pgp signature per binary	no
argocd	intoto and unsigned sha256sum	no
prometheus	unsigned sha256sum file	no
etcd	unsigned sha256sum file	no