Releases · researchxxl/syncthing-android · GitHub lists “Release attestation (json)” in the assets section. How is that generated and how does one verify it? I assume it’s meant to verify that the release artifacts were built from source by github but maybe that’s not correct.
It looks like a sigstore attestation but I’m unsure of the proper cosign commands to use. The github cli doesn’t work. gh attestation verify com.github.catfriend1.syncthingandroid_release_v2.0.13.1_arm64-v8a.apk -R researchxxl/syncthing-android fails with a 404. I looked through the github workflows and don’t see any references to cosign or github’s actions/attest action. Attestations · researchxxl/syncthing-android · GitHub is empty.
root@ab267eea8523:/# gh attestation verify syncthingfork_release_v2.0.13.1_arm64-v8a.apk \
--repo researchxxl/syncthing-android
Loaded digest sha256:0c745afce633ce6b0289c94b9a430943289bee6eabdd2f3dcbaff151a5241820 for file://syncthingfork_release_v2.0.13.1_arm64-v8a.apk
Loaded 1 attestation from GitHub API
✗ No attestations found with predicate type: https://slsa.dev/provenance/v1
root@ab267eea8523:/# gh attestation verify syncthingfork_release_v2.0.13.1_arm64-v8a.apk \
--repo researchxxl/syncthing-android \
--predicate-type https://in-toto.io/attestation/release/v0.2
Loaded digest sha256:0c745afce633ce6b0289c94b9a430943289bee6eabdd2f3dcbaff151a5241820 for file://syncthingfork_release_v2.0.13.1_arm64-v8a.apk
Loaded 1 attestation from GitHub API
The following policy criteria will be enforced:
- OIDC Issuer must match:................... https://token.actions.githubusercontent.com
- Source Repository Owner URI must match:... https://github.com/researchxxl
- Source Repository URI must match:......... https://github.com/researchxxl/syncthing-android
- Predicate type must match:................ https://in-toto.io/attestation/release/v0.2
- Subject Alternative Name must match regex: (?i)^https://github.com/researchxxl/syncthing-android/
✗ Sigstore verification failed
Error: verifying with issuer "GitHub, Inc."
According to the almighty AI, this package was signed while it was a private repo?
This is dangerous because i do not have knowledge about signing at all, so take this with a grain of salt. Here’s what the AI said:
The error “verifying with issuer ‘GitHub, Inc.’” indicates that the attestation was signed by GitHub’s private Sigstore instance (not the public one), but the GitHub CLI is trying to verify it against the public Sigstore infrastructure by default.
The Root Cause
Even though the repository is currently public, the attestations were generated when the repository was private or internal.
[…]
Since the attestations use GitHub’s private Sigstore instance (issuer “GitHub, Inc.”), you must use the offline verification method with the bundle file and specify the correct certificate identity:
However, this will still fail with the SourceRepositoryOwnerURI error, because attestations from GitHub’s private instance don’t include that certificate extension.
It would be nice to get an explanation exactly how we can verify the releases (built from source of this repo). @researchxxl
it is much easier in my concept than you think.. github automatically creates the attestation json when i do a new release because i set the immutable release option for the repo.. thats like github tells you hey i can assure you the release file are not modified after they first showed up publicly for download!! nothing more.. github does not assure how the app is signed nor which key is used for sign!! this helps to protect release files in case a bad actor take over my account and modifies the files after they are released.. immutable release imo is far not enough to mark a release as safe for you as it does not assure from which code it is built.. you get this assurance from fdroid because they build the app on their own and fully compare it to the protected github release files..
fdroid and immutable release imo is a strong assurance to you users that you really get whats on the public codebase on your phone no matter you download the app day one or another day after release
it does not assure you trust in one or more maintainers or contributed code
that is atm my responsibility to check contributions are safe and i did put safety nets in place using github ci reports as well
Thanks for the explanation. I wasn’t aware of github’s immutable release feature.
Is this the place to make feature requests? If so, I’d like to request adding artifact attestations via actions/attest-build-provenance so that users can use the github cli or cosign to verify build provenance (independent of fdroid).
