• Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

    From Alexander Traud@21:1/5 to All on Thu Nov 11 16:50:02 2021
    Many projects out there support not just a single crypto library like OpenSSL but others like GnuTLS and NSS as well. While building the project, a switch must be enabled or changed. Some projects even default not to OpenSSL. I saw Curl, which supports
    all three via six different packages, three runtime packages, and three -dev packages.

    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. Then, I would
    use that aid to file a wishlist on the bug tracking system for those projects, I know an alternative crypto library exists.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Alexander Traud on Thu Nov 11 17:10:01 2021
    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.)

    --
    Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to Russ Allbery on Thu Nov 11 17:40:01 2021
    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 searching didn't uncover any support for that belief.)
    https://fedoraproject.org/wiki/Fedora_Crypto_Consolidation https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGNRn8tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh vmoP/RTB5qL9FU2yz6TGZvcqCqiN3RNq0a7YmgwKQItJ2G+H162tW5MkdBQyWNsD geDIq2OGmORyD2jBj3g7fZrKuIrOM493NdR1hMsj+vqRFh35IG/b12MLJTGlk8nm DkfsruXAfgE3RW3Y6/AWr36mpjwPJy5abmQ8YGmeqBDUyyiEbOEty4VykwHd09gX eTJu6gL6UGrk8gxI8dLj1rU++1jf6p4MuKLiwe3euG+01+2HTOVt6oAOewJW/F8s zt3eopjBJoGdX/HrXI/IttcCia2lfrgBzx8U49r9EujnZsn80Kzcr4JUl+dzgLEa KLtUVaVC18S47T53ikCmdLnb5onWUREY/q8FmnnlqkuFVLPRKcLXX3igd8Jo40Pw lLsZq5F2xg6Ue057CUJp+r6iIwIgUWXsPqA07iNZ0ajtcvBgKF2zFEe5Qjfk+VB+ crgJBOS6+aJVSR+jBb5/OgXjXYrE8ixQokLU9OnnQwSPua4QBx+UNH2U3XNVgPxG Uj8zvx00Upw+mQ053TZiVVm3/JAYQG2o7s/G8u9HL4Bw+AYLbKDA2L9m3HXvP8vi 5I97yrypEoKK0DngDiJaMRxLiocUGYYblVH771cG8WHPfn42jiWQYDst2PddYJSi 2l4GuViJ0qPZIKHA/pFkaWzt6eN3y7zCRNRLpDRp9pXkNXlp
    =8XU1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Timo Aaltonen@21:1/5 to Russ Allbery on Thu Nov 11 17:30:01 2021
    On 11.11.2021 18.01, Russ Allbery wrote:
    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.)

    They stopped and moved pretty much everything on OpenSSL.


    --
    t

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrej Shadura@21:1/5 to Andrey Rahmatullin on Thu Nov 11 17:50:02 2021
    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 searching
    didn't uncover any support for that belief.)
    https://fedoraproject.org/wiki/Fedora_Crypto_Consolidation https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup

    Also relevant: https://www.apertis.org/concepts/tls-stack/

    --
    Cheers,
    Andrej

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrej Shadura@21:1/5 to Andrej Shadura on Thu Nov 11 18:00:02 2021
    Hi again,

    On Thu, 11 Nov 2021, at 17:47, Andrej Shadura wrote:
    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 searching
    didn't uncover any support for that belief.)
    https://fedoraproject.org/wiki/Fedora_Crypto_Consolidation
    https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup

    Also relevant: https://www.apertis.org/concepts/tls-stack/

    Actually, here’s the previous version of this document with more details: https://gitlab.apertis.org/docs/apertis-website/-/blob/84a9d6d9/content/concepts/tls-stack.md

    --
    Cheers,
    Andrej

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Biebl@21:1/5 to All on Thu Nov 11 20:30:02 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0vUljqRnnfJuEXZgVj3lAP4v
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQpPbiAxMS4xMS4yMSAxNzowMSwgUnVzcyBBbGxiZXJ5IHdyb3RlOg0KPiBBbGV4YW5kZXIg VHJhdWQgPHBhYnN0cmF1ZEBjb21wdXNlcnZlLmNvbT4gd3JpdGVzOg0KPiANCj4+IERlYmlh biBpcyB2ZXJ5IG11Y2ggT3BlblNTTC4gSG93ZXZlciwgSSBzZWUgc29tZSBwYWNrYWdlcyBk ZWZhdWx0IHRvDQo+PiBHbnVUTFMgb3IgZXZlbiBOU1Mgd2l0aG91dCBwcm92aWRpbmcgT3Bl blNTTCwgYWx0aG91Z2ggdGhlaXIgc291cmNlDQo+PiBwcm9qZWN0IHN1cHBvcnRzIGl0Lg0K PiANCj4gSGlzdG9yaWNhbGx5LCB1c2Ugb2YgR251VExTIHdhcyBtb3N0bHkgYmVjYXVzZSBv ZiBsaWNlbnNpbmcgcmVzdHJpY3Rpb25zDQo+IGJlY2F1c2UgT3BlblNTTCB3YXMgaW5jb21w YXRpYmxlIHdpdGggR1BMLWxpY2Vuc2VkIGNvZGUuICBOb3csIE9wZW5TU0wgaXMNCj4gY29t cGF0aWJsZSB3aXRoIEdQTCB2MyBhbmQgRGViaWFuIGhhcyAod2l0aCBzb21lIGNvbnRyb3Zl cnN5KSBhZG9wdGVkIGENCj4gcG9saWN5IG9mIHRyZWF0aW5nIGl0IGxpa2UgYSBzeXN0ZW0g bGlicmFyeSBldmVuIGZvciBHUEwgdjIgY29kZSwgc28gYXQNCj4gbGVhc3Qgc29tZSBvZiB0 aGUgR251VExTIHVzYWdlIGhhcyBzd2l0Y2hlZCB0byBPcGVuU1NMLg0KPiANCj4+IFF1ZXN0 aW9uKHMpOiBJcyB0aGVyZSBhIHJlY29tbWVuZGF0aW9uL2d1aWRlbGluZS9wb2xpY3kgdGhh dCBwYWNrYWdlDQo+PiBtYWludGFpbmVycyBzaG91bGQgcHJlZmVyIGEgc3BlY2lmaWMgY3J5 cHRvIGxpYnJhcnkgKE9wZW5TU0w/KSBpZiB0aGV5DQo+PiBjYW5ub3Qgc3VwcG9ydCBhbGwg b2YgdGhlbT8gSWYgbm90LCBpcyB0aGVyZSBhbiBhcmd1bWVudGF0aW9uIGFpZCB0bw0KPj4g Y29udmluY2UgcGFja2FnZSBtYWludGFpbmVycy4NCj4gDQo+IEkgZG9uJ3QgYmVsaWV2ZSB0 aGVyZSBpcyBhIHBvbGljeS4NCj4gDQo+IEluIHByYWN0aWNlLCBJIGJlbGlldmUgT3BlblNT TCB0ZW5kcyB0byBiZSBtb3JlIGludGVyb3BlcmFibGUgYW5kDQo+IGJldHRlci10ZXN0ZWQg dXBzdHJlYW0gdGhhbiBHbnVUTFMuICBUaGVyZSBoYXZlIGJlZW4gbG9uZy1zdGFuZGluZw0K PiBwcm9ibGVtcyB3aXRoIEdudVRMUyBub3QgaGFuZGxpbmcgd2VpcmQgY29ybmVyIGNhc2Vz IG9yIGJ1Z3MgaW4gb3RoZXINCj4gbGlicmFyaWVzLiAgU29tZSBvZiB0aGVzZSBkbyBnZXQg Zml4ZWQgb3ZlciB0aW1lLCBidXQgdGhhdCdzIHN0aWxsIG15DQo+IGdlbmVyYWwgaW1wcmVz c2lvbi4NCj4gDQoNCldoYXQgYSBjb2luY2lkZW5jZS4gSnVzdCB0aGUgb3RoZXIgZGF5IEkg cmVjZWl2ZWQNCmh0dHBzOi8vYnVncy5kZWJpYW4ub3JnL2NnaS1iaW4vYnVncmVwb3J0LmNn aT9idWc9OTk5Mzc1IGluIHJzeXNsb2cuDQoNCkhpc3RvcmljYWxseSwgSSd2ZSBsZWFuZWQg dG93YXJkcyBHbnVUTFMgbWFpbmx5IGZvciB0aGUgY2xlYW5lciANCmxpY2Vuc2luZyBzaXR1 YXRpb24gYW5kIGJlY2F1c2UgaXQgd2FzIG15IGltcHJlc3Npb24gdGhhdCBHbnVUTFMgd2Fz IHRoZSANCnByZWZlcnJlZCBUTFMgc3RhY2sgaW4gRGViaWFuLg0KDQpOb3dhZGF5cyBJJ20g bm90IHNvIHN1cmUgYW55bW9yZSwgZS5nLiBJJ20gZXZlbiBjb25zaWRlcmluZyBkaXNhYmxp bmcgDQpHbnVUTFMgc3VwcG9ydCBpbiBsaWJyZWxwLg0KDQpKdXN0IHdvbmRlcmluZyBpZiBh bnlvbmUgd291bGQgb2JqZWN0IHRvIHN1Y2ggYSBjaGFuZ2U/DQoNCk1pY2hhZWwNCg==

    --------------0vUljqRnnfJuEXZgVj3lAP4v--

    -----BEGIN PGP SIGNATURE-----

    wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmGNbZYFAwAAAAAACgkQauHfDWCPItxd Rg//dGk9BsaRyiA/IVhwcHA4j1FCODL+dIDgvkbaOzy5ERJNd27kAhWKlO1YM/S3BNsxlhD/UNIT goRkt7Jgyni/6KUQjZKUcgtpI/VkXxvZCF2f4oaJUHCJ7BpKMf9hR5uIHt7GMeCrMlHUuwbkgAK0 IilUhR8bowbuASqaE3CTWzeBqP6cWqqeMBqFVLuyiiRwi8XYCVv9WWpYTjZMzKYyhQ2ZXNe85ntL VT/FC5cA3Bssh/3sQxjNa1MlxshHcs4rVuYRJorFPZ2k3fKSEoL2qO/FvvII9CDEglC4vF6AwZMI 0YxVOucfY6BYIxIlRsxpeieueI9JD+OKsj4jOHOCYYan1BX7FtYUk/I+8XEc82qQ8Txy9fJjt5qT GArUkHrTQ5rRu9T+0him+EuPQdtTSTfA9K6yfR5gHisQiKYuqfgjUKKnmd6HlqWija3nvJDUhre8 3lNnAN+XXMTzsIk5sXAxx32lJmWXyc6SzcLtwLnSH7akOZLwJ+ne/YCgp9QDXXeckRpPopQ8iDdq pdI0tdcpABpaOyw+bCsHXgvb483ory7XkgFB/Cz0HZQCh7HWVUYA+m5tWMpIO2zNFjZZU/dTjjDc Hra8ci72rViaOGv6zuISJlwLRZrA0rwQKaYoOeGWCAe9K1uNj5Z7vakVvGU0daTf/eZVLlYEbw5E Pds=
    =2oXd
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Michael Biebl on Thu Nov 11 20:40:02 2021
    Michael Biebl <biebl@debian.org> writes:

    What a coincidence. Just the other day I received https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999375 in rsyslog.

    Yeah, this is exactly the sort of thing that I've seen with GnuTLS. While ideally one would work to debug and reproduce that problem and improve
    GnuTLS, switching to OpenSSL is a lot easier and makes most problems like
    this go away.

    --
    Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Laager@21:1/5 to Michael Biebl on Thu Nov 11 21:00:02 2021
    On 11/11/21 1:23 PM, Michael Biebl wrote:
    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?

    I would not. I force OpenSSL anyway. That is at least in part so we can
    use tls.tlscfgcmd to set CipherString, Ciphersuites, and MinProtocol per $DAYJOB's general TLS policy. It may also be because of issues with
    GnuTLS, I can't remember (and my comments/config messages don't indicate
    that).

    --
    Richard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephan =?ISO-8859-1?Q?Verb=FCcheln@21:1/5 to All on Fri Nov 12 13:10:02 2021
    Hello

    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.

    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.

    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. GnuPG is also a core dependency for any Debian installation that we will not get rid of.

    tl;dr: There are many different crypto libraries which more or less do
    the same thing, but we will not likely get rid of any.

    Regards
    Stephan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to All on Fri Nov 12 14:40:02 2021
    On Fri, 12 Nov 2021 at 12:03:53 +0000, Stephan Verbücheln wrote:
    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.

    I believe the reason why GNOME-adjacent projects generally prefer
    GnuTLS is that GNOME's conventional license is LGPL (or sometimes GPL), resulting in licensing conflicts between the (L)GPL's copyleft and the
    OpenSSL 1.x license's advertising clause.

    For permissively-licensed (non-copyleft) projects, OpenSSL's licensing
    is less of a barrier, and a lot of web projects are permissively-licensed,
    so it's unsurprising if they lean towards OpenSSL.

    In principle, GTK applications that require TLS should all or nearly
    all be using the TLS abstractions available in GLib since around 2011
    (such as GTlsConnection), which get their implementation from plugins
    rather than directly from GLib, so that distributions that feel strongly
    about this sort of thing can use their preferred implementation without
    having to patch GLib.

    The usual TLS plugins for GLib come from GNOME's glib-networking, which
    has both GnuTLS and OpenSSL backends (although I believe the OpenSSL
    backend is still considered experimental, and we don't compile it in
    Debian). Third-party plugins are also possible, but I don't think we
    have any in Debian.

    In practice, I'm sure some GNOME and GNOME-adjacent applications use
    GnuTLS, OpenSSL and/or NSS directly, either because they need finer
    control over TLS behaviour or because they are older than 2011 and never
    got converted to use GLib's TLS abstractions.

    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.

    My understanding is that libgcrypt is a low-level crypto library
    comparable to nettle/hogweed and OpenSSL's libcrypto, whereas GnuTLS
    is a higher-level TLS library comparable to OpenSSL's libssl.

    GnuTLS 2.x used libgcrypt, which it shared with GnuPG. GnuTLS 3.x uses nettle/hogweed instead.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rahmatullin@21:1/5 to All on Fri Nov 12 15:40:02 2021
    On Fri, Nov 12, 2021 at 12:03:53PM +0000, Stephan Verbücheln wrote:
    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.
    When you say "intentionally broke APIs to end the mess that OpenSSL was"
    you shouldn't say "0.9.x/1.x": https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

    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.
    Just like for 1.1? Or do you think it will be longer this time?

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmGOe6YtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh co8P/3n3BR3xUM0EP2r/3fGuMYY19H4GD9BBzior5ksFeLaHpGvRDpszAExLxP42 X0tyYER/fWrexhE2zqkgQuRPR+u1tbZcDFm7FUKdyUWzPI1CXWB7B/rJPBToClgv FaZijoc5Hswf2s/5w60eLSVmC3gpl4sxpSfGw0DVKoWm+yN/hb7J1/H88EeYHkj7 uAsAnMQi1alqvpilyCYsxy5E3CRp2QLbPOPR4TWTmhKcSD7vxA23bJVAhISc6s51 8nygFTqT5Oqs9dzID1HWvU3Vu6sUx62WSp2oz0cJCIVdaHOpe/Ek9JIxKJI+NzxZ /gPvVmFR8r1SR4Y/kjYDqOfRZ2RPUwO1yjXylEa89eZNROvd7DlSB3vQNO6bNuMI L9wT3/IJQLs0u6I7skAjiv6ylxuQFptKIZuayM3f8D59bjMa1FUPr2RVu2gKjp0U lnITN44pm6aBpl6CU55rn/DXrH/gDucMGE/Koz9qr+5VNhIZYPM2zD2+7MLKoyMy cw1/aByniOnWBuLU3aTnKuPga+jGX8RLEC/fS/+TARoDiK8eWbndRAeZHr4ZA9IQ dHH67x6n32Bjl0nvy/UPBl9F7ewuCFRCoy6xacvHLqJ65AhtY0S/AglBzhdG8/We vT3ZxhUAtrEkyqXx+MuLOJXTZZuG5lS9Srnzru3QFmjfytlF
    =4ys3
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to verbuecheln@posteo.de on Fri Nov 12 17:50:01 2021
    Stephan Verbücheln <verbuecheln@posteo.de> writes:

    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.

    I don't think the changes in OpenSSL 3.x are anywhere near as significant
    as the changes between Python 2 and Python 3. They seem largely in line
    with the kinds of changes that are always required when there's a new
    major OpenSSL release (and are far, far less significant than, say, the differences between the OpenSSL and GnuTLS APIs).

    --
    Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alexander Traud@21:1/5 to All on Mon Nov 29 16:50:01 2021
    you will not get rid of either crypto stack

    Thanks for everyone's comments. Sorry for the confusion introduced. I
    like one package each with a different crypto-library backend. Then, it
    is about user's choice rather than getting rid of something.

    My (observed) problem: Many projects *default* to one crypto library in
    their build system, sometimes not OpenSSL. However, the project supports
    more crypto libraries. Actually, the project – I am about – officially maintains and prefers OpenSSL as crypto-library backend, although it is
    not picked on default in their build system (for legacy reasons).

    And its package maintainer did not notice alternatives existed.

    My question was: Has anyone before evangelist on a Debian package
    maintainer to *add* another (-lib and -dev) package, with OpenSSL as crypto-library backend (or even more/all other crypto libraries) the
    upstream project supports? Very much like Curl does it right now. What
    could be arguments/reasons to convince the maintainer?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Goirand@21:1/5 to Alexander Traud on Tue Nov 30 15:20:02 2021
    On 11/29/21 4:47 PM, Alexander Traud wrote:
    What could be arguments/reasons to convince the maintainer?

    IMO, one good way to convince a maintainer, is to provide a patch... :)

    Cheers,

    Thomas Goirand (zigo)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)