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.

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.

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.

Why Blake2b?

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.

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.

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.

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

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

@Conan-Kudo That is fantastic news!

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.

@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.

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.

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.

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 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.