Re: rpm with sequoia pgp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux