RFE: Signing packages with signify

[hellcp]

Since it's a format that focuses as much on trust as on simplicity, it's a fitting replacement for signing packages. It's already used in OpenBSD since it was developed for it.

[D4N]

Somewhat related thread on fedora-packaging: https://lists.fedoraproject.org/archives/list/[email protected]/thread/WNR34OH3KVPKMGY4Z62CUPREEOVJJJNH/

[mlschroe]

You can sign with any tool you like as long as you wrap the result as a pgp signature.
I don't see any reason why we should use a different format for the signature.

(What we should do is support ed25519 though. We currently only support rsa and dsa)

[hellcp]

@mlschroe what @D4N pointed out would suggest it's not the best idea, I don't see why we shouldn't use a different format in that case

[mlschroe]

Why would we want to use a different format? There's nothing wrong with the pgp signature format. (I totally agree that the gpg code itself is horrible. Fortunately rpm does not use it.)

This is like saying we should switch to dpkg's packaging format because it is used by Debian.

[hellcp]

No, no, that's not the problem, the GnuPG's code doesn't matter in this case. The issue of PGP as a standard is the complexity, which translates into hard to understand process, which means it's way harder to understand what the basis of trust is in the system. If the users can't understand why they should trust the packages to be trustworthy, why would they trust our packages? Tools for signing and verification, as well as the process of signing by itself should be straightforward. Yes, that means using ed25519, but also a format that doesn't obfuscate the result in any way.

[mlschroe]

But rpm does not use any "web of trust" concept at all. And RFC 4880 also is not about trust.
In rpm a signature is valid if and only if the public key is in the database.

I think you're confusing the format with the implementation.

[hellcp]

Obviously, the trust is between the devs and the user, based on a repo key, why else would you sign the packages otherwise?

[mlschroe]

I don't understand that comment. Rpm's trust model is identical to the one used in signify.

[Conan-Kudo]

We might as well just use X.509 certificates and signatures like other operating systems do, then. At least those are better understood and implemented in more places than just GnuPG.

[mlschroe]

X.509? You mean PKCS#7? I don't think this would be an improvement ;-)

[Conan-Kudo]

PKCS#7 and PKCS#12, yes. At least we're not all strapped to GPG then. :)

[mlschroe]

But rpm does not use gpg for signature verification. Using PKCS#7 basically just means a different encoding format for the signature, the crypto libraries would not change at all.

It's much pain with no gain.

[Conan-Kudo]

While it's true RPM itself doesn't, most layers above RPM do, because that's pretty much the only way to do this. All of this stuff has consequences at higher levels of the stack (as I'm sure you're aware 😉).

Migrating from OpenPGP to PKCS#7 and PKCS#12 would make it easier for the ecosystem to transition from GPG to something more usable across the board.

[mlschroe]

You mean verification of metadata signatures? Is that what you want to change? For this it would make more sense if rpm offers an API so that it can do the verification. Currently upper layers have to export the keys from the rpmdb, import them into gpg (if they use gpg for this) and then use gpg for verification.

But we're hijacking this issue about signify by discussing something completely different. Could you please open another issue?

[DemiMarie]

IMO, moving from OpenPGP to PKCS#7 would hardly be a victory. Moving to something like Signify would.

Ideally, the signature would be at a fixed offset and of a fixed length, so there is no need to parse the file before checking the signature. That eliminates an enormous class of vulnerabilities.

[dralley]

I presume this would be out of scope for RPMv6?

[DemiMarie]

Much of the complexity in PKCS#7, PKCS#12, and OpenPGP comes from being too flexible.