This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Signing packages with signify #1193
Comments
Somewhat related thread on fedora-packaging: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/WNR34OH3KVPKMGY4Z62CUPREEOVJJJNH/ |
You can sign with any tool you like as long as you wrap the result as a pgp signature. (What we should do is support ed25519 though. We currently only support rsa and dsa) |
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. |
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. |
But rpm does not use any "web of trust" concept at all. And RFC 4880 also is not about trust. I think you're confusing the format with the implementation. |
Obviously, the trust is between the devs and the user, based on a repo key, why else would you sign the packages otherwise? |
I don't understand that comment. Rpm's trust model is identical to the one used in signify. |
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. |
X.509? You mean PKCS#7? I don't think this would be an improvement ;-) |
PKCS#7 and PKCS#12, yes. At least we're not all strapped to GPG then. :) |
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. |
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. |
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? |
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. |
Much of the complexity in PKCS#7, PKCS#12, and OpenPGP comes from being too flexible. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: