rpm-software-management / rpm-sequoia

An OpenPGP backend for rpm using Sequoia PGP
https://sequoia-pgp.org/
Other
14 stars 7 forks source link

preferred sequoia-openpgp crypto backend #30

Open decathorpe opened 1 year ago

decathorpe commented 1 year ago

As of version 1.13.0 of sequoia-openpgp, OpenSSL is now a supported crypto backend in addition to nettle, and I'm currently working on updating the Fedora packages for this crate, so this version will be available soon.

When switching to rpm-sequoia for Fedora 38 was discussed, many people seemed to prefer OpenSSL over Nettle as crypto backend if / when that became available. Would it make sense to build rpm-sequoia in Fedora with the openssl backend now? I can provide test builds in COPR if pushing it to rawhide "production" directly is not considered a good idea :)

nwalfield commented 1 year ago

I think the main people involved in the OpenSSL vs Nettle discussion on Fedora devel mailing list were: @pmatilai , @paulwouters , and @simo5. Perhaps they can share their opinion.

pmatilai commented 1 year ago

I think https://bugzilla.redhat.com/show_bug.cgi?id=2130122 would be a better place to discuss that Fedora specific decision, but since we're already here:

The short answer: yes.

The longer answer is that it may not be crucial to Fedora, but AIUI RHEL will want openssl and so the sooner we switch to that in Fedora, the more testing it will get -> the better. I'd update sequoia-openpgp to 1.13.0 first, give it a couple of days of spin in rawhide just in case and then flip it over to openssl. Should it blow up, you can always just untag the build :innocent:

paulwouters commented 1 year ago

On Jan 30, 2023, at 02:02, Panu Matilainen @.***> wrote: The longer answer is that it may not be crucial to Fedora, but AIUI RHEL will want openssl and so the sooner we switch to that in Fedora, the more testing it will getThat applies to Red Hat. Other people (eg my $dayjob) use fedora as the base OS and would also benefit from reducing the number of crypto libraries to a select few very well maintained and easily certifiable libraries. -> the better. I'd update sequoia-openpgp to 1.13.0 first, give it a couple of days of spin in rawhide just in case and then flip it over to openssl. Should it blow up, you can always just untag the build 😇AgreedPaul

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

simo5 commented 1 year ago

@decathorpe the reason to switch to OpenSSL is that OpenSSL has a stable ABI, while Nettle makes no promises, I think this is kind of important considering upgrade paths. Secondarily, in RHEL we FIPS certify OpenSSL, but not nettle standalone (nettle is only certified as part of GnuTLS), so OpenSSL is more compliant.

decathorpe commented 1 year ago

I think https://bugzilla.redhat.com/show_bug.cgi?id=2130122 would be a better place to discuss that Fedora specific decision, but since we're already here:

The default backend is defined in the upstream project, here: https://github.com/rpm-software-management/rpm-sequoia/blob/main/Cargo.toml#L47 Which is why I thought it would be good to talk about changing the default in upstream, which Fedora could then follow.

The short answer: yes.

The longer answer is that it may not be crucial to Fedora, but AIUI RHEL will want openssl and so the sooner we switch to that in Fedora, the more testing it will get -> the better. I'd update sequoia-openpgp to 1.13.0 first, give it a couple of days of spin in rawhide just in case and then flip it over to openssl. Should it blow up, you can always just untag the build innocent

Ok, sequoia-openpgp 1.13.0 is already in Rawhide, and it doesn't look like it's causing any build issues. I haven't merged the update to F37 and F36 yet because the OpenSSL test suite fails with OpenSSL < 3.0.7, but the failure looks harmless: https://gitlab.com/sequoia-pgp/sequoia/-/issues/979

Sounds like there is a general consensus that - while it's not as important in Fedora as it will be in RHEL - OpenSSL crypto backend would be preferred to Nettle. I will prepare a PR to change the defaults, and will provide test builds in a COPR.

decathorpe commented 1 year ago

FYI: Builds of rpm-sequoia in Fedora 38 and Rawhide have been using the OpenSSL crypto backend for two weeks now, so this change already went through F38 Beta validation etc. As far as I can tell, everything is looking solid, and no regressions have been reported.

nwalfield commented 1 year ago

@decathorpe : Thanks for the update!

pmatilai commented 1 year ago

@decathorpe : Oh, I hadn't noticed that at all. Thanks for letting us know!

nwalfield commented 1 year ago

The open question is: should the default be changed from nettle to openssl?

decathorpe commented 1 year ago

From my point of view that would make sense, given that the primary user (the package in Fedora) has already made the switch. And assuming other RPM based distros (OpenSUSE? Mageia?) will use rpm-sequoia in the future, the reasons for using the OpenSSL backend instead of Nettle will likely also be similar there (but if they want to use a different backend, they can always change the default).

nwalfield commented 1 year ago

@mlschroe indicated that OpenSUSE doesn't plan to switch in the next year or two. I don't know what Mageia plans and I don't have any contacts there.

pmatilai commented 1 year ago

I seem to recall @Conan-Kudo having some connections to Mageia :thinking:

Conan-Kudo commented 1 year ago

By the time the next Mageia release happens, it'll be a few years. If we manage to switch from URPMI to DNF in that timeframe, then it's possible it'll happen.

pmatilai commented 1 year ago

I fail to see how urpmi vs dnf would have anything to do with rpm crypto backend?

Conan-Kudo commented 1 year ago

Building rust software is quite problematic with our current package build infrastructure due to non-support for almost every RPM feature introduced since RPM 4.12.

pmatilai commented 1 year ago

Oh, okay. Fairly indirect connection then :smile: