On Thu, Jan 09, 2025 at 05:33:28PM +0100, Simon Josefsson wrote:
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?
In theory I don't see why "sigsum-release-verify" couldn't pull releases from more than one release page. What would probably happen if you have the same key for more than one project is: once you start releasing something new, someone that doesn't know about it will notice a "hidden release" that you can explain by telling them about the new project. And there would no longer be any hidden releases once they reconfigure.
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?
I haven't thought enough about it yet -- I think both could work, but I'm not sure which one is easier. What do you think sounds easier?
Btw, my release artifacts will be reproducible, I already check that in a GitLab pipeline.
Awesome -- and you'll be releasing on a GitLab release page? Or where will the tarballs and .proof files be available? Perhaps we can adapt age-release-verify to a prototype that works for your dogfooding?
-Rasmus