On Tue, Jan 14, 2025 at 08:48:38AM +0100, Simon Josefsson wrote:
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
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".
I think the "no hidden releases" ability is actually one of few practical immediate things an end-user gets from Sigsum but doesn't get from PGP.
So I'll try to adapt my workflow to make this possible, but I'm not yet sure how to do this.
Maybe this is a non-issue. Can you show me how to search the Sigsum log for any signature made by this public-key:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE
If there aren't any, I didn't manage to push anything into the log, so I should be able to use this key for sigsum signing of release artifacts going forward. And be careful to never sign anything except properly released artifacts.
Otherwise I have to generate a new private-key for my Sigsum release signing.
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.
Right, agreed, passing private key around is bad, let's avoid that.
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.
I will post links once I managed to iterate into actual releases of the projects I want to do this for. I think GitLab release pages, Savannah download area, and ftp.gnu.org distributions cover my use-cases.
Great! In the mean time I filed this:
https://git.glasklar.is/rgdd/age-release-verify/-/issues/1
-Rasmus