Hi Paul, Thanks for your comments.
On Fri, 02 Sep 2022 20:21:21 +0200, Paul Wouters wrote: > On Fri, 2 Sep 2022, Neal H. Walfield wrote: > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > I think this should be considered a blocker for changing gpg backends. That's a decision for Fedora. I have no strong preference. (For what it's worth, rpm doesn't use gpg. rpm has an internal OpenPGP backend, which was developed in house.) > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Note2: There are lots of reasons to use Sequoia, but one user-visible > > reason is improved usability. When a user imports a certificate, > > Sequoia lints it and displays potential issues, or reasons why it > > can't be imported: > > > > > > https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174 > > > > $ rpm --import peter-expired-backsig.pgp > > Certificate 251C20A67D942D45: > > Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z > > Certificate does not have any usable signing keys > > > > Whereas before rpm would just say: > > > > error: peter-expired-backsig.pgp: key 1 import failed. > > That seems like a fairly minor point to change backends and crypto > library for and could be something that can be fixed in the current > backend as well? I spent some time looking at and trying to improve rpm's OpenPGP implementation. It's quite hairy. See, for example, this issue: https://github.com/rpm-software-management/rpm/issues/2004 Even Panu (rpm's maintainer) does not have great confidence in the OpenPGP parser's robustness: I think the only safe assumption is to assume it a bug in rpm's parser. Shock horror :laughing: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-1096286416 If you want to have a look at the code, here's a good place to start: https://github.com/rpm-software-management/rpm/blob/d703160/rpmio/rpmpgp_internal.c#L965 I suspect that this hairiness is because the internal OpenPGP parser started as a minimal implementation to handle data generated by GnuPG when it was written about 20 years ago. Panu writes: https://github.com/rpm-software-management/rpm/pull/1813#discussion_r790681223 the rpm implementation strives to do the bare minimum to get by https://github.com/rpm-software-management/rpm/issues/1978#issuecomment-1080606598 The current "API" is ad-hoc stuff added over the course of 20 years, by people with not much OpenPGP experience. I'm sure it shows. And, over time it has grown in complexity to accommodate new requirements, like support for RFC 4880, and subkeys. Whatever the case, Panu doesn't want to invest more time into it: https://github.com/rpm-software-management/rpm/issues/1935 There's something seriously wrong when a significant percent of package manager development discussions is about OpenPGP specification and its interpretation in the RPM context. This is negatively impacting development of RPM "core business", to the point that this has to stop. There's exactly one way to stop it, and that's getting rid of the internal parser, one way or the other. Targeted for RPM 4.19 in 2023, and this also means that no major developments to the existing parser should be done, from here on it's strictly in critical fixes only -mode. Those are reasons against the internal OpenPGP implementation. But, I also want to briefly say why I (a co-founder of the Sequoia project), think that Sequoia is a good choice. In Sequoia we've spent a lot of time trying to get the little details right. In particular, we invested a lot of effort in certificate canonicalization, which is essential to making sure OpenPGP certificates are interpreted in a sane way. There is a nice write up of why this is hard by the author of PGPainless: https://blog.jabberhead.tk/2021/04/03/why-signature-verification-in-openpgp-is-hard/ When I first thought about signature verification in OpenPGP I thought “well, it cannot be that hard, right?”. In the end all you got to do is check if a signature was made by the given key and if that signature checks out (is cryptographically correct). Oh boy, was I wrong. (For the haters: yes, OpenPGP is complicated, but I suspect this type of complexity will be present in some form of another is all PKIs that support expirations, revocations, etc.) It's due to this infrastructure that Sequoia is so often able to return informative error messages that go to the root cause of the problem. While developing Sequoia, we didn't just rely on our interpretation of the RFC. We also looked at what other implementations were doing and tried to push the whole ecosystem forward. This is demonstrated through Justus' work on the OpenPGP interoperability test suite: https://tests.sequoia-pgp.org/ Please share any other concerns you may have so that we can discuss them. :) Neal _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
