Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

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

 



On 10/13/22 08:14, Neal Gompa wrote:
> On Thu, Oct 13, 2022 at 4:24 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote:
>>
>> On 10/13/22 10:53, Neal Gompa wrote:
>>> On Thu, Oct 13, 2022 at 3:29 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote:
>>>>
>>>> On 10/13/22 07:18, Kevin Kofler via devel wrote:
>>>>>> For the last 20 years or so, RPM has used a home-grown OpenPGP parser
>>>>>> for dealing with keys and signatures. That parser is rather infamous
>>>>>> for its limitations and flaws, and especially in recent years has
>>>>>> proven a significant burden to RPM development. In order to improve
>>>>>> security and free developer resources for dealing with RPM's "core
>>>>>> business" instead, RPM upstream is in the process of deprecating the
>>>>>> internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
>>>>>> based solution written in Rust.
>>>>>
>>>>> Why are you using a new library written in Rust? Can you not use one of the
>>>>> existing mature C implementations of OpenPGP? gpgme maybe?
>>>>
>>>> Had there been such an option, we would've switched over years ago.
>>>> Gpgme is based around calling and communicating with an external gpg
>>>> process, which is a setup you do NOT want in the rpm context where
>>>> chroots come and go etc. Also, rpm requires access to the "low-level"
>>>> digests-in-progress because it calculates multiple things on a single read.
>>>>
>>>
>>> The real problem is that all other OpenPGP implementations died out
>>> because of GnuPG. And then GnuPG made the choice to force an
>>> inter-process model.
>>>
>>> At work, I deal with this on Debian systems, which do indeed use GnuPG
>>> for this. It creates a lot of problems, especially for building images
>>> and dealing with chroots, which is why in the context of RPM PGP
>>> upstream, I never pushed to consider it.
>>>
>>> The most serious problems with PackageKit memory leaks and hangs are
>>> actually caused by GnuPG, since DNF uses it for some GPG stuff because
>>> there's no API for using RPM's PGP capabilities. There's no fix unless
>>> the RPM and DNF teams agree on an API and build it out so that libdnf
>>> and librepo no longer need to use GnuPG through gpgme anymore.
>>>
>>> This is also the underlying reason why Red Hat has resisted
>>> implementing signed repository metadata and enforcing it by default.
>>> Of course this is a bit of a catch-22 as well, as there's no
>>> motivation to find a solution because neither Fedora nor RHEL offer
>>> signed repository metadata despite repeated calls for it over the past
>>> decade.
>>>
>>> Now, don't get me wrong: I'm personally extremely unhappy about having
>>> to depend on the Sequoia stack for RPM PGP. I have a strong distaste
>>> for the Rust community ecosystem these days, and I don't love the idea
>>> of having to have LLVM in the core bootstrap chain (hopefully gcc-rs
>>> will be in place soon enough!). But we literally don't have any other
>>> options. GnuPG/GPGME is out of the question for the reasons Panu and I
>>> stated, and NeoPG died several years ago. There are no C/C++ libraries
>>> for OpenPGP verification.
>>
>> There's RNP (in C++, used by Thunderbird at least), but alas that
>> doesn't expose the digest-in-progress either. So at least in it's
>> current form, it's not an option for rpm. Also, the API appears to have
>> all manner of quirks and gotchas that aren't welcome in a
>> security-critical piece.
>>
> 
> Huh, I'd forgotten about RNP. It seems it now has an OpenSSL backend
> and at least the verification API (which is what RPM would use) seems
> to be getting love lately. Insofar as quirks and gotchas, I'm not a
> great judge of that at the moment, but I don't think it could be worse
> than what we have with GnuPG.
> 
> The missing "digest-in-progress" thing is an issue, I guess. Have we
> raised the issue with them about it?
> 
>> As for bootstrap, there will always (have to) be a way to build rpm
>> without depending on Rust. Even if that meant no signature verification
>> support in such a configuration.
>>
> 
> Eck. What about the x509 based stuff we were talking about last year?
> All the crypto backends RPM supports now support that stuff out of the
> box.
> 
> Embedded x509 signatures (certs) to replace GPG signatures could work
> as an alternative.

OpenPGP is not great, but X.509 is an absolute disaster in comparison.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
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