rpm with sequoia pgp

[Neal H. Walfield]

Hi all,

rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
Sequoia PGP.

  https://rpm.org/wiki/Releases/4.18.0
  https://sequoia-pgp.org/

Thanks to Fabio Valentini (decathorpe) for packaging not only
rpm-sequoia, but all of the Sequoia packages for Fedora.

 
https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...


With this note, I'd firstly like to make the Fedora community more
aware of this project.  (I don't think it has been mentioned here
yet.)

Second, although the internal OpenPGP backend is still the default
backend, it will be removed in rpm 4.19:

  https://github.com/rpm-software-management/rpm/issues/1935

It is probably best to start the transition as soon as possible to
work out any kinks.

In that vein, I'd like to offer my help.  Making this type of change
needs to be done carefully.  Perhaps these are questions or concerns.
I'd like to hear them and respond to them.  There is also technical
work that needs to be done.  I'm more of a developer than a packager,
but if Fedora decides to use the Sequoia backend, I'd like to offer my
help in any way I can.



Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
work to port it to Sequoia to OpenSSL:

  https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...

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-1...

  $ 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.

Thanks,

:) Neal

[Paul Wouters]

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.

>  
> https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
>
>  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-1...
>
>   $ 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?

Of course if upstream rpm is moving, I think fedora should do so as well
to keep in line with upstream, but to me that really does imply not
using nettle but using openssl.

Paul

[Neal H. Walfield]

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-1...
>  > 
>  > 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-1...
>  > 
>  >  $ 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-1...

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_...

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_r7906...

   the rpm implementation strives to do the bare minimum to get by

   https://github.com/rpm-software-management/rpm/issues/1978#issuecomment-1...

   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-openp...

  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

[Alexander Sosedkin]

Quoting Neal H. Walfield (2022-09-02 16:31:18)
>  rpm 4.18 is on the horizon and includes a new OpenPGP backend based
> on
>  Sequoia PGP.
>
>    https://rpm.org/wiki/Releases/4.18.0
>    https://sequoia-pgp.org/
>
>  Thanks to Fabio Valentini (decathorpe) for packaging not only
>  rpm-sequoia, but all of the Sequoia packages for Fedora.
>
>   
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
>
>
>  With this note, I'd firstly like to make the Fedora community more
>  aware of this project.  (I don't think it has been mentioned here
>  yet.)
>
>  Second, although the internal OpenPGP backend is still the default
>  backend, it will be removed in rpm 4.19:
>
>    https://github.com/rpm-software-management/rpm/issues/1935
>
>  It is probably best to start the transition as soon as possible to
>  work out any kinks.
>
>  In that vein, I'd like to offer my help.  Making this type of change
>  needs to be done carefully.  Perhaps these are questions or concerns.
>  I'd like to hear them and respond to them.  There is also technical
>  work that needs to be done.  I'm more of a developer than a packager,
>  but if Fedora decides to use the Sequoia backend, I'd like to offer my
>  help in any way I can.
>
>
>
>  Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
>  work to port it to Sequoia to OpenSSL:
>
>    https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
Mind the
https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies

Will we need to introduce a configuration mechanism to limit algorithm
selection in Sequoia PGP? Or just wait untl it switches to OpenSSL?

>  ...

[Fabio Valentini]

On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin <asosedki(a)redhat.com&gt; wrote:
>  Quoting Neal H. Walfield (2022-09-02 16:31:18)
>  > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
>  > Sequoia PGP.
>  >
>  >   https://rpm.org/wiki/Releases/4.18.0
>  >   https://sequoia-pgp.org/
>  >
>  > Thanks to Fabio Valentini (decathorpe) for packaging not only
>  > rpm-sequoia, but all of the Sequoia packages for Fedora.
>  >
>  >  
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
>  >
>  >
>  > With this note, I'd firstly like to make the Fedora community more
>  > aware of this project.  (I don't think it has been mentioned here
>  > yet.)
>  >
>  > Second, although the internal OpenPGP backend is still the default
>  > backend, it will be removed in rpm 4.19:
>  >
>  >   https://github.com/rpm-software-management/rpm/issues/1935
>  >
>  > It is probably best to start the transition as soon as possible to
>  > work out any kinks.
>  >
>  > In that vein, I'd like to offer my help.  Making this type of change
>  > needs to be done carefully.  Perhaps these are questions or concerns.
>  > I'd like to hear them and respond to them.  There is also technical
>  > work that needs to be done.  I'm more of a developer than a packager,
>  > but if Fedora decides to use the Sequoia backend, I'd like to offer my
>  > help in any way I can.
>  >
>  >
>  >
>  > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
>  > work to port it to Sequoia to OpenSSL:
>  >
>  >  
> https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
>
>  Mind the
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies
>
>  Will we need to introduce a configuration mechanism to limit algorithm
>  selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? 
Isn't this handled at the level of the crypto library?
OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow
system crypto policy, just as OpenSSL does?
For example, I don't see anything related to crypto policies in the
gnupg2 package, either.

Fabio

[Alexander Sosedkin]

On Mon, Sep 5, 2022 at 10:55 AM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin <asosedki(a)redhat.com&gt; wrote:
>  >
>  > Quoting Neal H. Walfield (2022-09-02 16:31:18)
>  > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
>  > > Sequoia PGP.
>  > >
>  > >   https://rpm.org/wiki/Releases/4.18.0
>  > >   https://sequoia-pgp.org/
>  > >
>  > > Thanks to Fabio Valentini (decathorpe) for packaging not only
>  > > rpm-sequoia, but all of the Sequoia packages for Fedora.
>  > >
>  > >  
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
>  > >
>  > >
>  > > With this note, I'd firstly like to make the Fedora community more
>  > > aware of this project.  (I don't think it has been mentioned here
>  > > yet.)
>  > >
>  > > Second, although the internal OpenPGP backend is still the default
>  > > backend, it will be removed in rpm 4.19:
>  > >
>  > >   https://github.com/rpm-software-management/rpm/issues/1935
>  > >
>  > > It is probably best to start the transition as soon as possible to
>  > > work out any kinks.
>  > >
>  > > In that vein, I'd like to offer my help.  Making this type of change
>  > > needs to be done carefully.  Perhaps these are questions or concerns.
>  > > I'd like to hear them and respond to them.  There is also technical
>  > > work that needs to be done.  I'm more of a developer than a packager,
>  > > but if Fedora decides to use the Sequoia backend, I'd like to offer my
>  > > help in any way I can.
>  > >
>  > >
>  > >
>  > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
>  > > work to port it to Sequoia to OpenSSL:
>  > >
>  > >  
> https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
>  >
>  > Mind the
>  > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies
>  >
>  > Will we need to introduce a configuration mechanism to limit algorithm
>  > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL?
>
>  Isn't this handled at the level of the crypto library? 
That's my question, really: does it need extra configuration generated
or will it just attempt a low-level library operation and fail gracefully
when it finds the operations blocked?

>  OpenPGP uses nettle for cryptography purposes, shouldn't *that*
> follow
>  system crypto policy, just as OpenSSL does?
>  For example, I don't see anything related to crypto policies in the
>  gnupg2 package, either. 
Unfortunately, nettle and gnupg2 don't follow crypto-policies (yet?).
It's only beginning to expand beyond networking protocols (TLS/SSH/KRB...).

[Neal H. Walfield]

On Mon, 05 Sep 2022 10:12:23 +0200,
Alexander Sosedkin wrote:
>  Mind the
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies
>  
>  Will we need to introduce a configuration mechanism to limit algorithm
>  selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? 
Good question.

Sequoia has a flexible mechanism to describe its cryptographic policy:

  https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy...

There isn't yet a way to configure it using a configuration file, but
that is doable.  Here's the issue, fwiw:

  https://gitlab.com/sequoia-pgp/sequoia/-/issues/857

One potential issue is that OpenPGP fingerprints are computed using
SHA-1.  In practice this is not a security problem as fingerprints
don't need collision resistance, just second pre-image resistance,
which SHA-1 still has.

The upcoming version of the OpenPGP specification specifies SHA2
256-based fingerprints

 
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-0...

But we won't be able to switch immediately: users would have to create
new certificates, and old certificates would have to fall out of use.

Neal

[Dan Čermák]

Hi Neal,

"Neal H. Walfield" <neal(a)walfield.org&gt; writes:

>  Hi all,
>
>  rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
>  Sequoia PGP.
>
>    https://rpm.org/wiki/Releases/4.18.0
>    https://sequoia-pgp.org/
>
>  Thanks to Fabio Valentini (decathorpe) for packaging not only
>  rpm-sequoia, but all of the Sequoia packages for Fedora.
>
>   
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
As Sequoia is written in Rust, what is your RISCV story? Fedora is (at
least that's my impression) a quite popular choice for RISCV boards, so
rpm working on RISCV would be crucial for us staying relevant.


Cheers,

Dan

[Fabio Valentini]

On Mon, Sep 5, 2022 at 2:18 PM Dan Čermák
<dan.cermak(a)cgc-instruments.com&gt; wrote:
>  Hi Neal,
>
>  "Neal H. Walfield" <neal(a)walfield.org&gt; writes:
>
>  > Hi all,
>  >
>  > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
>  > Sequoia PGP.
>  >
>  >   https://rpm.org/wiki/Releases/4.18.0
>  >   https://sequoia-pgp.org/
>  >
>  > Thanks to Fabio Valentini (decathorpe) for packaging not only
>  > rpm-sequoia, but all of the Sequoia packages for Fedora.
>  >
>  >  
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
>
>  As Sequoia is written in Rust, what is your RISCV story? Fedora is (at
>  least that's my impression) a quite popular choice for RISCV boards, so
>  rpm working on RISCV would be crucial for us staying relevant. 
I don't think architecture support is a problem.
This might have been an issue when Rust was relatively new, but the
list of supported targets is pretty big now:
https://doc.rust-lang.org/nightly/rustc/platform-support.html

For example, RISC-V (riscv64gc-unknown-linux-gnu) is supported by the
Rust toolchain at the same level (Tier 2) as three other architectures
we have (armv7hl / armv7-unknown-linux-gnueabihf, ppc64le /
powerpc64le-unknown-linux-gnu, s390x / s390x-unknown-linux-gnu). Only
x86 (x86_64-unknown-linux-gnu / i686-unknown-linux-gnu) and aarch64
(aarch64-unknown-linux-gnu) have better support (Tier 1).

Fabio

[Neal H. Walfield]

Hi Dan,

On Mon, 05 Sep 2022 14:18:05 +0200,
Dan Čermák wrote:
>  "Neal H. Walfield" <neal(a)walfield.org&gt; writes:
>  As Sequoia is written in Rust, what is your RISCV story? Fedora is (at
>  least that's my impression) a quite popular choice for RISCV boards, so
>  rpm working on RISCV would be crucial for us staying relevant. 
This is a valid concern, and one that I'm also worried about.

According to this web page:

  https://fedoraproject.org/wiki/Architectures/RISC-V

Fedora wants to support the RV64GC architecture, which I think
corresponds to riscv64gc-unknown-linux-gnu.  The Rust project
indicates that riscv64gc-unknown-linux-gnu is a Tier 2 architecture:

  https://doc.rust-lang.org/nightly/rustc/platform-support.html

FWIW, Fedora also supports armv7hl (armv7-unknown-linux-gnueabihf) and
s390x-unknown-linux-gnu, which are also Tier 2 Rust architectures, but
which have Rust packages:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1939157

So, I guess the bad news is that RISCV is not Tier 1, but the good
news is that Tier 2 is already pretty good.

Relatedly, I hear that Linux will start using Rust.  I suspect that as
that happens, a lot more resources will be invested in making sure
Rust has good support on all of the platforms that Linux supports.

Finally, rpm 4.18 will support both the internal OpenPGP parser and
the Sequoia-based parser.  So, if the Sequoia-based parser proves
inadequate for some platforms (e.g., it doesn't compile or the test
suite fails), Fedora can still fallback to the internal parser on that
platforms.  Note, though, that the internal OpenPGP parser is slated
to be removed in 4.19:

  https://github.com/rpm-software-management/rpm/issues/1935

Neal

[Panu Matilainen]

On 9/2/22 17:31, Neal H. Walfield wrote:
>  Hi all,
>  
>  rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
>  Sequoia PGP.
>  
>     https://rpm.org/wiki/Releases/4.18.0
>     https://sequoia-pgp.org/
>  
>  Thanks to Fabio Valentini (decathorpe) for packaging not only
>  rpm-sequoia, but all of the Sequoia packages for Fedora.
>  
>    
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
>  
>  
>  With this note, I'd firstly like to make the Fedora community more
>  aware of this project.  (I don't think it has been mentioned here
>  yet.)
>  
>  Second, although the internal OpenPGP backend is still the default
>  backend, it will be removed in rpm 4.19:
>  
>     https://github.com/rpm-software-management/rpm/issues/1935 
While that was the initial goal, I suspect we may have to stretch this a 
bit. I think we'll first need a release where the upstream default is 
something else, and then in the next release we can actually look at 
axing it.

>  
>  It is probably best to start the transition as soon as possible to
>  work out any kinks.
>  
>  In that vein, I'd like to offer my help.  Making this type of change
>  needs to be done carefully.  Perhaps these are questions or concerns.
>  I'd like to hear them and respond to them.  There is also technical
>  work that needs to be done.  I'm more of a developer than a packager,
>  but if Fedora decides to use the Sequoia backend, I'd like to offer my
>  help in any way I can. 
Since rpm 4.18 gained the Sequoia support afterall, we can and should 
look into swapping over in Fedora 38. That'll help sorting out any rough 
edges and make it easier to eventually swap the default in upstream as 
well. We probably need to do this with a change process as anything 
rpm-related tends to be system/distro wide in a sense (see below)

Once the dust from 4.18 has settled (final is expected in a couple of 
weeks) we can start digging into this, although nothing prevents 
starting with other "paperwork" etc.

>  Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
>  work to port it to Sequoia to OpenSSL:
>  
>     https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
This may well be a blocker on Fedora level, in part to keep container 
etc images small but also for distro crypto policies and FIPS (neither 
of which nettle supports AIUI).

	- Panu -

[Simo Sorce]

On Tue, 2022-09-06 at 11:09 +0300, Panu Matilainen wrote:
>  On 9/2/22 17:31, Neal H. Walfield wrote:
>  > Hi all,
>  > 
>  > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
>  > Sequoia PGP.
>  > 
>  >    https://rpm.org/wiki/Releases/4.18.0
>  >    https://sequoia-pgp.org/
>  > 
>  > Thanks to Fabio Valentini (decathorpe) for packaging not only
>  > rpm-sequoia, but all of the Sequoia packages for Fedora.
>  > 
>  >   
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
>  > 
>  > 
>  > With this note, I'd firstly like to make the Fedora community more
>  > aware of this project.  (I don't think it has been mentioned here
>  > yet.)
>  > 
>  > Second, although the internal OpenPGP backend is still the default
>  > backend, it will be removed in rpm 4.19:
>  > 
>  >    https://github.com/rpm-software-management/rpm/issues/1935
>  
>  While that was the initial goal, I suspect we may have to stretch this a 
>  bit. I think we'll first need a release where the upstream default is 
>  something else, and then in the next release we can actually look at 
>  axing it.
>  
>  > 
>  > It is probably best to start the transition as soon as possible to
>  > work out any kinks.
>  > 
>  > In that vein, I'd like to offer my help.  Making this type of change
>  > needs to be done carefully.  Perhaps these are questions or concerns.
>  > I'd like to hear them and respond to them.  There is also technical
>  > work that needs to be done.  I'm more of a developer than a packager,
>  > but if Fedora decides to use the Sequoia backend, I'd like to offer my
>  > help in any way I can.
>  
>  Since rpm 4.18 gained the Sequoia support afterall, we can and should 
>  look into swapping over in Fedora 38. That'll help sorting out any rough 
>  edges and make it easier to eventually swap the default in upstream as 
>  well. We probably need to do this with a change process as anything 
>  rpm-related tends to be system/distro wide in a sense (see below)
>  
>  Once the dust from 4.18 has settled (final is expected in a couple of 
>  weeks) we can start digging into this, although nothing prevents 
>  starting with other "paperwork" etc.
>  
>  > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
>  > work to port it to Sequoia to OpenSSL:
>  > 
>  >   
> https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
>  
>  This may well be a blocker on Fedora level, in part to keep container 
>  etc images small but also for distro crypto policies and FIPS (neither 
>  of which nettle supports AIUI). 
With my Crypto Team hat on I do not see this as a blocker for Fedora in
the short term, we can start with nettle and then move to OpenSSL
later.

For RHEL we may prefer OpenSSL for various reasons above, but I would
note that although we do not certify nettle directly under FIPS we do
indirectly as part of GnuTLS, so it is certainly tested cryptography.

In fact nettle might be a slightly better choice in some cases for
container images because it is much smaller than OpenSSL.

Finally nettle could even be statically built into sequoia (together
with gmp) if we need even smaller footprint or we are concerned about
potential rpm breakage during upgrades.
I am not saying we want to do this, but it is an option that OpenSSL 3
won't provide as easily.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Panu Matilainen]

On 9/6/22 23:10, Simo Sorce wrote:
>  On Tue, 2022-09-06 at 11:09 +0300, Panu Matilainen wrote:
> > On 9/2/22 17:31, Neal H. Walfield wrote:
> >> Hi all,
> >>
> >> rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
> >> Sequoia PGP.
> >>
> >>     https://rpm.org/wiki/Releases/4.18.0
> >>     https://sequoia-pgp.org/
> >>
> >> Thanks to Fabio Valentini (decathorpe) for packaging not only
> >> rpm-sequoia, but all of the Sequoia packages for Fedora.
> >>
> >>    
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/pa...
> >>
> >>
> >> With this note, I'd firstly like to make the Fedora community more
> >> aware of this project.  (I don't think it has been mentioned here
> >> yet.)
> >>
> >> Second, although the internal OpenPGP backend is still the default
> >> backend, it will be removed in rpm 4.19:
> >>
> >>     https://github.com/rpm-software-management/rpm/issues/1935
> >
> > While that was the initial goal, I suspect we may have to stretch this a
> > bit. I think we'll first need a release where the upstream default is
> > something else, and then in the next release we can actually look at
> > axing it.
> >
> >>
> >> It is probably best to start the transition as soon as possible to
> >> work out any kinks.
> >>
> >> In that vein, I'd like to offer my help.  Making this type of change
> >> needs to be done carefully.  Perhaps these are questions or concerns.
> >> I'd like to hear them and respond to them.  There is also technical
> >> work that needs to be done.  I'm more of a developer than a packager,
> >> but if Fedora decides to use the Sequoia backend, I'd like to offer my
> >> help in any way I can.
> >
> > Since rpm 4.18 gained the Sequoia support afterall, we can and should
> > look into swapping over in Fedora 38. That'll help sorting out any rough
> > edges and make it easier to eventually swap the default in upstream as
> > well. We probably need to do this with a change process as anything
> > rpm-related tends to be system/distro wide in a sense (see below)
> >
> > Once the dust from 4.18 has settled (final is expected in a couple of
> > weeks) we can start digging into this, although nothing prevents
> > starting with other "paperwork" etc.
> >
> >> Note: Sequoia currently uses Nettle on Fedora, but there is ongoing
> >> work to port it to Sequoia to OpenSSL:
> >>
> >>    
> https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1...
> >
> > This may well be a blocker on Fedora level, in part to keep container
> > etc images small but also for distro crypto policies and FIPS (neither
> > of which nettle supports AIUI).
>  
>  With my Crypto Team hat on I do not see this as a blocker for Fedora in
>  the short term, we can start with nettle and then move to OpenSSL
>  later.
>  
>  For RHEL we may prefer OpenSSL for various reasons above, but I would
>  note that although we do not certify nettle directly under FIPS we do
>  indirectly as part of GnuTLS, so it is certainly tested cryptography.
>  
>  In fact nettle might be a slightly better choice in some cases for
>  container images because it is much smaller than OpenSSL. 
Yup. My assumption was that since openssl will be pulled in "anyway", 
anything else will be seen as unwanted size increase. But, I hadn't 
realized nettle is *that* much smaller.

>  
>  Finally nettle could even be statically built into sequoia (together
>  with gmp) if we need even smaller footprint or we are concerned about
>  potential rpm breakage during upgrades.
>  I am not saying we want to do this, but it is an option that OpenSSL 3
>  won't provide as easily. 
Ack. Highly useful info this all, thanks!

	- Panu -

>  
>  Simo.
>