sigul

#19 Signing RPMs fails on newer RPM versions (at least F34+)
Opened by ertzing. Modified

Open
Close Issue

In RPM 4.14 V4 signatures were introduced. SIgul expects RPM v3 type signatures in the pipeline. Newer rpmsign binaries (like the one on F34 at least) require the --rpmv3 parameter to generate signatures that sigul likes. Omitting the parameter will lead to the bridge rejecting signed files from the server, stating they're not signed (they are, just not in a way sigul recognizes). This happens when running sigul as part of a pipeline that pushes the signatures to koji.

The solution to this is not really obvious to me, detecting whether or not the rpmsign binary on the server needs this flag sounds somewhat fragile.

Hey,

Thanks for the report!
I hit this myself as well during some development I'm doing on Sigul, and this should be fixed in the next release, that should be due relatively soon.

Regards,
Patrick

Erm. Rpm v4 signatures were NOT introduced in 4.14, they were introduced in 4.0, over twenty years ago. What recently happened is that rpm 4.16 stopped creating rpm v3 signatures by default, for packages that don't need them (as in, have a separate payloaddigest hash).

Of course, those "v3" signatures (meaning signature on combined header+payload data) having always been there, it's not inconceivable that other software still expects them to be there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.