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