Debian is very much OpenSSL. However, I see some packages default to
GnuTLS or even NSS without providing OpenSSL, although their source
project supports it.
Question(s): Is there a recommendation/guideline/policy that package maintainers should prefer a specific crypto library (OpenSSL?) if they
cannot support all of them? If not, is there an argumentation aid to
convince package maintainers.
(Didn't Red Hat attempt to standardize on NSS a while back? I feel likehttps://fedoraproject.org/wiki/Fedora_Crypto_Consolidation https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup
that didn't work and they stopped that effort, but some quick searching didn't uncover any support for that belief.)
Alexander Traud <pabstraud@compuserve.com> writes:
Debian is very much OpenSSL. However, I see some packages default to
GnuTLS or even NSS without providing OpenSSL, although their source
project supports it.
Historically, use of GnuTLS was mostly because of licensing restrictions because OpenSSL was incompatible with GPL-licensed code. Now, OpenSSL is compatible with GPL v3 and Debian has (with some controversy) adopted a policy of treating it like a system library even for GPL v2 code, so at
least some of the GnuTLS usage has switched to OpenSSL.
Question(s): Is there a recommendation/guideline/policy that package
maintainers should prefer a specific crypto library (OpenSSL?) if they
cannot support all of them? If not, is there an argumentation aid to
convince package maintainers.
I don't believe there is a policy.
In practice, I believe OpenSSL tends to be more interoperable and better-tested upstream than GnuTLS. There have been long-standing
problems with GnuTLS not handling weird corner cases or bugs in other libraries. Some of these do get fixed over time, but that's still my
general impression.
Also, if a software package was written to use OpenSSL, the OpenSSL compatibility layer in GnuTLS is very limited (I say this as someone who tried to use it for a package for several years) and tends to cause a lot
of problems.
NSS probably doesn't have the same interoperability problems. I
personally have no opinions about using it. (Didn't Red Hat attempt to standardize on NSS a while back? I feel like that didn't work and they stopped that effort, but some quick searching didn't uncover any support
for that belief.)
On Thu, Nov 11, 2021 at 08:01:54AM -0800, Russ Allbery wrote:
(Didn't Red Hat attempt to standardize on NSS a while back? I feel likehttps://fedoraproject.org/wiki/Fedora_Crypto_Consolidation https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup
that didn't work and they stopped that effort, but some quick searching
didn't uncover any support for that belief.)
Hi,
On Thu, 11 Nov 2021, at 17:36, Andrey Rahmatullin wrote:
On Thu, Nov 11, 2021 at 08:01:54AM -0800, Russ Allbery wrote:
(Didn't Red Hat attempt to standardize on NSS a while back? I feel like >>> that didn't work and they stopped that effort, but some quick searchinghttps://fedoraproject.org/wiki/Fedora_Crypto_Consolidation
didn't uncover any support for that belief.)
https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup
Also relevant: https://www.apertis.org/concepts/tls-stack/
What a coincidence. Just the other day I received https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999375 in rsyslog.
Nowadays I'm not so sure anymore, e.g. I'm even considering disabling
GnuTLS support in librelp.
Just wondering if anyone would object to such a change?
My impression is that web based projects lean towards OpenSSL, while
for example the whole GTK/Gnome desktop stack is using GnuTLS (with nettle/hogweed). So you will not get rid of either crypto stack.
An then there is NSS by Mozilla, and there is also libgcrypt, which is
the basis of GnuPG. To my knowledge, it does not even share core
routines with GnuTLS.
Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x haveWhen you say "intentionally broke APIs to end the mess that OpenSSL was"
to be treated like two completely different libraries. They have
different licenses and intentionally broke APIs to end the mess that
OpenSSL was.
It is a situation like Python 2 and 3, we will have both around for aJust like for 1.1? Or do you think it will be longer this time?
long time, because upstream code has to be ported to new APIs.
Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have to
be treated like two completely different libraries. They have different licenses and intentionally broke APIs to end the mess that OpenSSL
was. It is a situation like Python 2 and 3, we will have both around for
a long time, because upstream code has to be ported to new APIs.
you will not get rid of either crypto stack
What could be arguments/reasons to convince the maintainer?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 70:14:27 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,485 |