Replies: 1 comment
-
|
Hello @anoncam, Thanks for your interest in the project and your valuable feedback! You are right to flag that a non-notarized app seems suspicious but we don't consider this a "gap" since one of the design goals of the project is to exclude ourselves (and ideally any intermediates) from a user's trusted computing base (TCB). That being said, we will improve our documentation to add the steps you can use to verify the client. For now, here are a couple of ways with which you can verify the artifact we publish today: Using Github's release attestationAlongside our release artifacts, you can also find a "Release attestation" json file. This is Github's published "release attestation" and can essentially be used similarly to a $ gh release verify v1.20.0
Resolved tag v1.20.0 to sha1:8f32af3e8d3ed928ea3e85079fd7ec621f9e1dca
Loaded attestation from GitHub API
✓ Release v1.20.0 verified!
Assets
NAME DIGEST
contrast-aarch64-darwin sha256:78869784ea09b130439ee3fe768d03d55a2c71811483740e0365b6c4434f3229
...
$ sha256sum contrast-aarch64-darwin
78869784ea09b130439ee3fe768d03d55a2c71811483740e0365b6c4434f3229 contrast-aarch64-darwinThis allows you to verify that the artifact you downloaded is the artifact that was published as part of the release by Github. Reproducible buildIf you are not interested in having Github in your trusted computing base (TCB) though, the contrast client is bit-by-bit reproducible, so you can audit the code, build it and verify it against our published artifact: git clone https://github.com/edgelesssys/contrast
git checkout v1.20.0
git describe --tags --exact-match | sed 's/^v//' | tr -d '\n' | tee version.txt
# review code
# You can follow https://github.com/edgelesssys/contrast/blob/main/CONTRIBUTING.md#development-setup in an aarch64-darwin system
nix build .#base.contrast.cli-release; git checkout -- version.txt
...
$ sha256sum result/bin/contrast
78869784ea09b130439ee3fe768d03d55a2c71811483740e0365b6c4434f3229 result/bin/contrastPlease don't hesitate to raise any other inconsistencies you may find. Cheers, Spyros |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Big fan of the project. Quick question on the macOS install path documented at howto/install-cli.
Steps to reproduce
sudo xattr -d com.apple.quarantine contrastExpected behavior
Some path — any path — for verifying the binary that will serve as the root of trust for every attestation downstream. A
cosign verify-blobinvocation. A Sigstore bundle reference. A published SHA256SUMS next to the release. Notarization. A detached GPG signature like it's 2014. Literally anything.Actual behavior
The install instructions for an attestation product instruct the user to disable the OS's only built-in code-signing check, with no alternative verification step offered.
The curl path on the same page isn't meaningfully more trustworthy — curl just doesn't set com.apple.quarantine, so LaunchServices never gets a chance to complain. The trust boundary in both cases is "TLS to github.com plus the assumption that no one has ever pushed a bad tag."
Proposed fix
Add a verification step before install. Something along the lines of:
Or, at absolute minimum, publish
SHA256SUMSon the release and reference it in the docs.Severity
Cosmetic, but the kind of cosmetic that gets flagged during a SLSA-aware procurement review and makes the rest of the trust story harder to sell.
Beta Was this translation helpful? Give feedback.
All reactions