Don’t do GPG signature checking on Fedora and derivatives

[mavit]

Fedora are aiming to enforce GPG signature checking on all RPM packages. We don’t sign our packages, so that will fail.

https://fedoraproject.org/wiki/Changes/Enforcing_signature_checking_by_default

A better solution would, of course, be to actually sign the packages and distribute the keys, perhaps even via our own Yum repository. Better still would be to get LMS included in Fedora, but for that we need to unbundle any remaining non-free firmware and, ideally, switch to upstream versions of all bundled CPAN modules.

We don't need to make this change until Fedora 44 releases in April 2026, but I'm raising this now before I forget. It looks like it won't even work until rpm-software-management/dnf5#2479 is fixed.

[michaelherger]

So you're saying in the future we will have to explicitly tell dnf to not check the signature, otherwise installation would fail? And documenting this is the best we can do other than providing a correctly set up repository? Would you know how much effort it would be to set something up? In terms of code, signing keys etc.? We can certainly provide the infrastructure to host something. But someone would have to take ownership of the maintenance etc.

[mavit]

So you're saying in the future we will have to explicitly tell dnf to not check the signature, otherwise installation would fail?

That’s Fedora’s plan, yes.

And documenting this is the best we can do other than providing a correctly set up repository? Would you know how much effort it would be to set something up? In terms of code, signing keys etc.?

As I understand it, the signing process is loosely:

• Generate a GPG keypair for, say build@lyrion.org.
• Keep the private key safe.
• Distribute the public keys to users, somehow.
• Configure RPM to sign with build@lyrion.org’s key.
• Modify the build process to run rpmsign --addsign … after rpmbuild ….

We don’t strictly need the repository, but it helps with distributing the public keys, and it’s how everyone else does it, these days, so it’s probably easier than inventing and documenting our own idiom. A side benefit would be that the OS would take care of updates for users.

The steps for setting up a repository would be:

• Create an additional RPM (called, say, lyrion-release), containing repository metadata and the public key.
• Run createrepo_c on the directory containing the RPMs, and include the output on the download server.
• Change our installation instructions to be:
  1. Download and install the lyrion-release package.

  2. sudo dnf install lyrionmusicserver

We can certainly provide the infrastructure to host something. But someone would have to take ownership of the maintenance etc.

If we could remove the last few remaining non-Free components (I think it’s just the firmware and a font?) from the package, we could point Fedora Copr at the spec file, and have it automatically build and sign RPMs, and host repositories for us.

It would build specific packages per distribution version and architecture, so in the future we could look to take advantage of this to shrink packages by leaving out components for irrelevant Perl versions.

I think this is the best way to go, if we can do it.

[michaelherger]

Would you be willing and able to take care of that? Would using that Copr service even still require us to host anything?

And shall I merge this PR while we can continue the discussion?