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.
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.
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.
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
/Simon