Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
What the tool does right now is basically this:
Locate all releases at: https://api.github.com/repos/FiloSottile/age/releases
The above API is documented here: https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28
Then what happens is that the tool downloads the respective release assets. In the case of age, some tarballs with binaries + .proofs.
Then the tool does sigsum-verify. So far nothing very exciting is happening, but it is now e.g. possible to notice if Filippo forgot to upload .proof files. Which he did, and which I noticed. Wink wink. :)
The tool is currently also shelling out for each asset, with the intent to rebuild the asset and ensure Filippo's binary is correct for the respective git tags. But that part is TODO, see this week's minutes:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/202...
Okay, now the cool part. The tool downloads every entry from sigsum log(s), filtering on the keys Filippo use to create his .proof files. Finally, the tool computes the diff between what Filippo published on the release page and what checksums he signed and published in Sigsum. If there's something in the log that he didn't publish -> hidden release. Now you know, and you can conversate about it with filippo.
Thank you! This helps to understand it.
But how would this work if I release two different projects with the same public key?
Don't you need the ability to enumerate all software releases made by the same public key, not just per project?
My plan has been to do a couple of releases and publish *.proof files for them. Maybe using the same public key is then not the best idea any more? And your approach suggests it is better to use a per-project private key, to allow this kind of "No hidden release" monitoring in a simple way?
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
/Simon