multiple signatures support?

[nirik]

The rpmsign man page says:

"Both of the --addsign and --resign options generate and insert new signatures for each package PACKAGE_FILE given, replacing any existing signatures. There are two options for historical reasons, there is no difference in behavior currently."

But:

https://github.com/rpm-software-management/rpm/blob/1b338aa84d4c67fefa957352a028eaca1a45d1f6/doc/manual/format
and
https://github.com/rpm-software-management/rpm/blob/1b338aa84d4c67fefa957352a028eaca1a45d1f6/doc/manual/signatures

indicate that multiple signatures are possible/supported.

Is there any way to sign an rpm with multiple gpg keys?

[mikem23]

Note that there is potentially a huge impact on tools that assume that rpms can only be singly signed.

[pmatilai]

Technically speaking, there's no inherent limitation to just one signature because the header as a data structure can store fairly arbitrary amount of data. But no, multiple signatures per package is not implement currently.

[nirik]

Ah, bummer. Are there any plans to implement this anytime soon?

Our use case is around Fedora branching time... if we could sign rpms with both the F(n)+1 (rawhide) and F(n) (branched) keys we could hardlink them and handle the change of keys in mock and such easier.

Of course this would need koji changes also ( https://pagure.io/koji/issue/363 )

[pmatilai]

I've been looking at various things related to rpm signatures and their handling, and multiple signatures happens to be one of them.

Your use-case is not just a matter of more signatures though, it'd require a particular verification policy and a way to express that within rpm as well, roughly: between multiple signatures of same type (signer role-wise) it's sufficient to have one that verifies and others can be ignored.

You couldn't possibly have brought that use-case up at a better time, because in my early plans that case simply wouldn't have been possible. No promises at this point, except that I will take this into consideration at least.

[nirik]

Great. Note that koji devs were thinking perhaps moving to detached sigs would be the way to go... but thanks for looking at this.

[mikem23]

The advantage of a detached signature is that you don't have to modify something in order to certify it. The disadvantage is that you have to have both parts to validate.

Rpms are often signed with multiple keys over their lifetime. Embedded signatures force us to choose between keeping mostly redundant copies, or forever throwing away the previous signed copy. Koji dodges this by having the ability to rip out an rpm signature header and splice it back in later, effectively detaching the embedded signature.

[jcpunk]

I'll confess some interest in this myself. Though my use case is a bit different. I'm looking at the transition to ECM keys from RSA keys. I'd like to play with them a bit first. The ability to sign with both key types helps me make sure my ECM only system is really using the same packages as my non-ECM system.

[jcpunk]

I was actually thinking of Elliptic Curve Method based crypto. Though Enterprise Content Management signatures might also be interesting.

[pmatilai]

Dusted off an earlier and nearly lost and forgotten work on this in #1050, comments and other feedback welcome.

[DemiMarie]

I am strongly in favor of detached signatures, for multiple reasons:

• Detached signatures can be verified without having to parse the RPM at all. This dramatically reduces the attack surface ― only the PGP signature parser and the crypto code remains.
• Detached signatures can be verified without the involvement of RPM. This means that one can use whatever signature format they desire, rather than being limited to what RPM supports. For instance, someone could use OpenBSD’s signify (or its compatible replacement minisign) instead.
• Detached signatures mean that supporting multiple signatures is trivial.
• Detached signatures can be created without using RPM, which reduces the attack surface of the signing system.
• Detached signatures work for any file whatsoever, not just RPMs. This means that a signing and verification pipeline can use the same code for all files, rather than having to special-case specific kinds of files. If there was a generic signed container format, this would also work, but (to my knowledge) no such format exists (yet).
• Detached signatures get RPM out of the crypto business. RPM is a package manager. Let RPM handle what it is good at, and let the cryptographic tools handle what they are good at.

[JanZerebecki]

Note that it is also useful to be able to verifying an installed rpms content against the signature, without having to download the rpm.

Detached signatures can be verified without the involvement of RPM.

It would only work if there is no embedded signature and there is no other data removed or added for the signature. It might be a long time until distributions are willing to leave the embedded signature out. Until then, to be able to make use of multiple signatures one would need to involve rpm to verify them.

Supporting multiple detached signatures makes checking an rpm for being an reproducible build much easier. The additional signatures come from somewhere else at a later time. Only supporting embedded signatures would mean needing to rewrite the rpm after the download. Or using two entirely different ways to verify an rpm.

[pmatilai]

Restarting this in #3385 with an actual plan.