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.
On Wed, Jan 08, 2025 at 02:09:21PM +0100, Sigsum General wrote:
Thanks for explaining! Sounds good. Could a tool like 'age-release-verify' be made independent of GitHub?
Yes, and I hope the above blurb helps describe how. Replace enumeration of GitHub's API with say GitLab's API, or even more plain listings like https://dist.system-transparency.org/st/. It doesn't matter where the data is downloaded from, as long as you know how to enumerate it.
For us who doesn't like to think too hard, could there be some documentation explaining exactly how the tool works? What requests are made to where, and how? How is it searching for hidden releases?
Yes -- I probably won't do it for the age-release-verify repository because it's a quick hacky prototype. But I'd like a more proper demo with such documentation, similar to www.sigsum.org/getting-started but focused on this particular use-case rather than just signed checksums.
Could all of the data be supplied on the command-line instead? Except, presumably, for the online Sigsum log queries that have no offline serialized artifact?
Yes, that's what I'm doing in this (slighly more documented) demo:
https://git.glasklar.is/rgdd/sshdt https://git.glasklar.is/rgdd/sshdt/-/blob/main/Makefile?ref_type=heads#L42
-Rasmus
/Simon
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
On Tue, Jan 07, 2025 at 09:08:08PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
Use the .proof file to verify the Sigsum proof. These files are like signatures with extra transparency: you can cryptographically verify that every proof is logged in a public append-only log, so you can say with confidence what signatures exists. This helps to protect against secret (targetted and/or malicious) releases.
If you want some inspiration for why the above paragraph is true:
https://git.glasklar.is/rgdd/age-release-verify
I'd love to see a similar prototype for your use-case!
Neat!
Could that tool be extended to do the same for arbitrary release proofs, not only 'age'? Maybe call it be 'sigsum-release-verify'?
That's an interesting idea -- I think it would be extensible yes. The current prototype should already work for any GitHub release page, so I don't see why it wouldn't be possible to make this into a tool that knows how to fetch releases from various common APIs / release pages. And then it optionally hands over to a user-supplied script that does rebuilding (i.e., the actual rebuilding is not in scope of the tool).
Could this functionality be built into 'sigsum-verify'?
It could, yes. But it's a different type of verification (online and with linear overhead) so I think it probably deserves its own tool.
Or could the functionality of 'sigsum-verify' be built into 'sigsum-release-verify'?
That's actually what the prototype does right now -- it does sigsum-verify and checks (online) that there are no hidden releases.
Having a small dedicated purpose tool similar to 'gpgv' but doing Sigsum signature verification against some trust policy and/or checking for hidden releases would be good for release announcement instructions.
It would be nice if users doesn't have to run two separate tools to do these checks, if they can be done quickly at the same time.
As hinted on above, the problem is sigsum-release-verify would not be so efficient that it completes in reasonable time for every user that wants to install something. I think more of this as: I install something and ensure sigsum-verify is happy -> that means *someone else* that runs the more expensive sigsum-release-verify can tell if I'm being owned.
So it's detection after-the-fact rather than proactive prevention.
But I like the idea of still having something about how to run this verification in the release announcement, because that's what it's all about: *there's a claim, and it is possible to verify the claim*.
I suppose checking for hidden releases is an online operation?
Yes, correct!
Bonus points for a python or C client too :)
Hehe, I'm sure that will be available some day. Nothing that we're currently hacking on right now though, contributions welcome! :)
-Rasmus _______________________________________________ Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org
Sigsum-general mailing list -- sigsum-general@lists.sigsum.org To unsubscribe send an email to sigsum-general-leave@lists.sigsum.org