RFE: Detached signature support

[DemiMarie]

For RPMv6, we can replace the signature header with detached signatures. To quote my comment on another issue:

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.

Because of the above properties, detached signatures integrate well with tools like The Update Framework (TUF). TUF handles signature verification itself, and treats packages as opaque blobs. In such a system, having RPM try to validate signatures is pointless.

If we still need to support embedded signatures, we can have a signature section that is just a series of length-prefixed blobs. Prior to validation, these would be extracted and removed from the RPM file.

[Conan-Kudo]

Detached signatures are problematic for mirrored content because it's very difficult to guarantee that those files are synced together. It's also difficult to guarantee consumers will have signatures to validate. That's the reason why Debian tooling generally doesn't support signed packages and nothing really generates or validates debsigs. I'd rather continue to have a contiguous blob with signatures in the RPM header like we do now.

[DemiMarie]

That’s understandable. Ideally, this blob would be as simple as possible; the current signature blob is more complicated than necessary. What about a Blake2b hash of the lead+header+payload, followed by a list of (length, timestamp, expiration, Blake2b hash of (algorithm ID||public key), raw binary signature blob) tuples? The signature would be over the Blake2b hash of all data between the package hash (inclusive) and the signature blob (exclusive). This would include the signature’s own length, timestamp, expiration date, and (algorithm ID||public key) hash. The list would be terminated by a signature of length zero.

[DemiMarie]

Some of the advantages of this approach:

• The initial hash covers the entire package, and does not need to be updated when signatures are added or removed.
• Multiple signatures are automatically supported.
• Signatures are timestamped and can expire.
• Key fingerprints include the algorithm as part of the hash, so if there are no trusted keys that use a certain algorithm, that algorithm cannot be used.

[Conan-Kudo]

Why Blake2b?

[DemiMarie]

Fast and has a massive security margin. I believe the best known attacks are on 3 rounds vs 12, and libsodium has a hyper-optimized SIMD implementation it uses for Argon2.

[pmatilai]

Rpm will have to support the embedded signatures for just about forever more, but there's no reason rpm couldn't support detached signatures as an alternative, it's just a piece of OpenPGP data that could come from anywhere if there was an API for it. But detached signatures aren't any magic solution to all signature problems, it's just a different set of compromises from the embedded ones.

[mlschroe]

Also note that rpm's signatures are like a second line of defense. The first line is the repository metadata, which uses detached signatures and checksums over the complete files.

[DemiMarie]

@mlschroe Sadly, Fedora doesn’t sign its metadata.

[Conan-Kudo]

@DemiMarie The first steps towards making it possible to do that are being done now: https://pagure.io/koji/pull-request/2637

[DemiMarie]

@Conan-Kudo That is fantastic news!

[ffesti]

There is a middle way how to deal with signatures: Append at the end of the package. RPM should probably dictate a way how they should be separated. Then one could just read the last few kB of the package and check for signatures there without understanding the rpm format at all. You could also put signatures there that are completely unknown to rpm.
One could encode them with base64 or something similar to be 100% sure nothing can go wrong.

[nirik]

@mlschroe Sadly, Fedora doesn’t sign its metadata.

We don't need to as we use metalinks. In the metalink is the checksum(s) for the valid repomd.xml file. If someone tampers with the repodata it will not match and the client will go on to the next one. But thats likely offtopic for this issue... so I will stop there.

[JanZerebecki]

Detached signatures are problematic for mirrored content because it's very difficult to guarantee that those files are synced together.

The same problem already exists for different rpms that depend on each other. The meta data of a repository is also already spread over multiple files. (I still see rare reports for mirrors failing this way.)

That's the reason why Debian tooling generally doesn't support signed packages and nothing really generates or validates debsigs.

My memory is hazy, but I don't think that is the reason. Debian package repositories also have multiple files that need to be available from the same generation for it to work.

My main interest in detached signatures is for multiple additional ones for reproducible builds.

[DemiMarie]

Detached signatures are problematic for mirrored content because it's very difficult to guarantee that those files are synced together.

The same problem already exists for different rpms that depend on each other. The meta data of a repository is also already spread over multiple files. (I still see rare reports for mirrors failing this way.)

One solution to all of these problems is to never update a file (except the root metadata file) in-place, and instead have every other file in the repository be addressed by hash.

[JanZerebecki]

That doesn't solve the problem, as the new root still references files that may not yet have been mirrored, you'd also need a distributed protocol for it to work. The solution without a distributed protocol is on a mirror to download the files in a new directory (possibly a cow or hardlinked copy) and only once the new one is verified rename the new over the old. This works for all package managers and is already required today. So this is not something preventing detached signatures (which would never be updated).

[DemiMarie]

That doesn't solve the problem, as the new root still references files that may not yet have been mirrored, you'd also need a distributed protocol for it to work. The solution without a distributed protocol is on a mirror to download the files in a new directory (possibly a cow or hardlinked copy) and only once the new one is verified rename the new over the old. This works for all package managers and is already required today. So this is not something preventing detached signatures (which would never be updated).

That is a good point, and with BTRFS snapshots it should be very easy to implement.