The future of artifact signing in Fedora

Project Discussion
1

Hi infrastructure folks,

I wanted to start a discussion about the future of signing services in Fedora. Right now, we use sigul and robosignatory. I wrote a brief blog post about how everything works together in case you’re not familiar or want a refresher.

Unfortunately, sigul depends on python-nss, which is unmaintained upstream and not available in Fedora 42. The server runs on RHEL9, so this isn’t an immediate problem, but it will be an issue soon. I recently wrote a new sigul client implementation as part of some other work, so I’m now reasonably familiar with how things work, and I’m also in a position where I can dedicate some time to re-writing the sigul server and bridge services.

However, there are rumbling about potentially using Konflux in Fedora. I inquired about how signing would work in the Konflux matrix channel and @ralph said:

[…] we have a release pipeline task that can talk to a process similar to robosignatory via activemq. It’ll certainly need updating, but that’s one option: request signatures via fedora-messaging. It is arguably inefficient. I’m looking forward to some work other Red Hatters are doing to manage signing requests via hashicorp vault. If that proves to work well, it could be an option for Fedora too.

This leads me to what I would like to discuss. What direction would Fedora infrastructure like to pursue longer term? Is there a desire to continue with sigul (in some form) or to align with what Red Hatters are working on with Hashicorp Vault?

There’s pros and cons to both, and some uncertainty. I know Hashicorp was recently acquired, but I don’t know that Vault will revert its usage of the Business Source License. Konflux in Fedora is still an open question without a timeline I’m aware of, and I don’t know the details of how signing would work beyond the quote above. On the other hand, writing and maintaining an application is work. It’s work I’m happy to do, but maintenance lasts forever and I am, as far as I know, mortal.

2

My preference is to avoid moving to a non free/open source as a service
thing if we can at all avoid it.

I guess that ends up meaning sigul, unless we can find another existing
open source project that does (or could be made to do) what we need it
to do?

I’ve found sigstore interesting, but it… really doesn’t do what we do
now at all, although perhaps we could adapt to it somehow.

There might be some other things out there, not sure.

kevin

3

I did look at sigstore, it seems like an interesting project, but aimed providing ways to validate who published a particular thing (so like, who tagged this release, or created and uploaded this tarball) and, in particular, using OpenID Connect for identifying who signed things. I can see how it’d be useful to us when, say, pulling in a new release from upstream, but not for signing things ourselves. Of course, I only read the docs and it’s always possible I’ve misunderstood how it works.

It’s a bit a of niche so it’s difficult to know where to search beyond how other distributions handle things. Maybe @ngompa knows how the openSUSE package and SecureBoot signing works, or at least where to look at those details. I can inquire with a teammate about how Debian handles things, as well.

Edit: for Debian, I think they use dak and some other utilities for signing. It’s pretty Debian-specific (quite unsurprisingly) so I’m not sure there’s too much we can share there. I’ll continue looking through it though.