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/packa...
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-1219...
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-1081...
$ 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
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-1219...
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-1081...
$ 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
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-1219...
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-1081...
$ 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-1096...
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_int...
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_r7906812...
the rpm implementation strives to do the bare minimum to get by
https://github.com/rpm-software-management/rpm/issues/1978#issuecomment-1080...
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-...
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
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/packa...
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-1219...
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?
...
On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin asosedki@redhat.com 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/packa...
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-1219...
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
On Mon, Sep 5, 2022 at 10:55 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin asosedki@redhat.com 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/packa...
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-1219...
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...).
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.ht...
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-06#s...
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
Hi Neal,
"Neal H. Walfield" neal@walfield.org 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/packa...
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
On Mon, Sep 5, 2022 at 2:18 PM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi Neal,
"Neal H. Walfield" neal@walfield.org 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/packa...
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
Hi Dan,
On Mon, 05 Sep 2022 14:18:05 +0200, Dan Čermák wrote:
"Neal H. Walfield" neal@walfield.org 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
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/packa...
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:
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-1219...
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 -
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/packa...
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:
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-1219...
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.
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/package/rust-rpm-sequoia/
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-1219175000
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.