@pmatilai converted this issue into discussion #2753.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1193#event-10898660507
You are receiving this because you are subscribed to this thread.
Message ID:
Much of the complexity in PKCS#7, PKCS#12, and OpenPGP comes from being too
flexible.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
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
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
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this
PKCS#7 and PKCS#12, yes. At least we're not all strapped to GPG then. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
X.509? You mean PKCS#7? I don't think this would be an improvement ;-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We might as well just use X.509 signatures like other operating systems do,
then. At least those are better understood and implemented in more places than
just GnuPG.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I don't understand that comment. Rpm's trust model is identical to the one used
in signify.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Obviously, the trust is between the devs and the user, based on a repo key, why
else would you sign the packages otherwise?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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.
--
You are receiving this because you are subscribed to this
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
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.
--
You are
@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
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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)
--
You are receiving this because you
Somewhat related thread on fedora-packaging:
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/WNR34OH3KVPKMGY4Z62CUPREEOVJJJNH/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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](https://www.openbsd.org/papers/bsdcan-signify.html).
--
You are receiving this because you are subscribed to this
18 matches
Mail list logo
