On Mon, Jan 13, 2025 at 02:28:46PM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
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.
Oh. I'm not sure I can commit to this key life-cycle management myself. I am a bit too used to do "test" releases that involve full signatures and complete announcements, that look like the real things. I may have already pushed out "hidden releases" for my existing SSH public-key when I have tested your tools.
Another option is to only use Sigsum *for you* to be able to verify what happens with your signing key. For example, you kindly ask folks to sigsum-verify, and what that facilitates is that only you can meaningfully run sigsum-monitor (or a more production-worthy tool in the future) that notifies *you* whenever there is a new sigsum signature.
Presumably, you (but nobody else) would know when you intended to sign something. So this would help you detect when your key is compromised, but it wouldn't help others to detect if you're signing secret stuff.
This is a perfectly good use of Sigsum as well -- no need to go all the way and make additional claims and involve "sigsum-release-verify".
So maybe I have to generate a new personal private key used for Sigsum-based release signing, and only use it when I really want to commit to a particular release forever. That seems to match the semantics that your tool would be testing for.
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?
I fear there is no simple answer, this seems like a key management issue that is beyond what tools can help with.
Yep, agreed.
Consider if I a co-maintainer wants to sign a new release, I wouldn't want to share my general-purpose private key with that person, but it may be reasonable to have a sigsum "no hidden release" per-project long-term private key and pass it around between maintainers, at least for as long as it is possible to keep it protected. On the other hand, then there would be no single person to Have A Conversation With in case of a hidden release, so this approach may be a bad idea.
I would probably make each co-maintainer have a separate sigsum key, just like each co-maintainer currently would have a separate PGP key. The sigsum-release-verify tool takes as input all (co-)maintainer keys, and can then pin-point who (which key) signed off a hidden release.
Wrt. "pass around the key approach" -- not ideal, but a silverlining is that you could at least detect when the key is compromised with Sigsum.
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?
I am using many different workflows. Some projects use GitLab release pages, some uses GitLab but releases are pushed elsewhere, and some projects aren't using GitLab at all. Some produce the release artifacts in the GitLab pipeline, some don't.
But I'm happy to pick some project to use for experimentation, to iterate on this. Libntlm has been my typical toy project to experiment releases processes with. https://gitlab.com/gsasl/libntlm/-/releases
If you can point me towards a GitLab release page (like the above) that has tarballs (or similar) + .proof, then I can try to best-effort adapt age-release-verify to work for that. Should be pretty quick unless I run into something unexpected when trying to use the GitLab API.
-Rasmus