5 ms·

Who is OpenSSL and why do they sell expensive support contracts? It sounds like 1.1.1 is only EOL if you don't pay.

by fh973 3y ago

kstrauser 3y ago
Isn't that almost always the case with FOSS projects? For instance, throw enough money at Red Hat and I bet they'd support anything you'd like for as long as you'd want.
- fh973 3y ago
  No, not at all ! It can only be the case of the maintaining entity is the one that sells support. That's actually the definition of commercial software! It may be the case for company-backed FOSS projects (that use FOSS as a marketing channel and have a business model around it). You might be used to that because Redhat, Elastic, Mongo, ... But for very large number of FOSS projects, that's not the case. Either there is no paid support, or it is done by a third-party. But then this third party doesn't call the shots what's deprecated and what's backported where. I was under the impression that OpenSSL is a community project, and now it appears that that's not the case.
aaomidi 3y ago
OpenSSL is the dependency for doing TLS and a lot more. It’s effectively one of the only options. Crypto is hard, and crypto in C is fucking awful. Hence the pricing.
- dharmab 3y ago
  BoringSSL, wolfSSL, LibreSSL, not to mention the various FIPS options.
  - aaronmdjones 3y ago
    ARM mbedTLS is one of my favourites. Excellent documentation.
  - TheDong 3y ago
    I think GnuTLS is probably the second most popular TLS library, after openssl. Though actually, maybe, firefox's NSS is now that I think about it a second more. Firefox is at least some fraction of C-library-based ssl traffic out there. I'll also mentions s2n and rustls-ffi for completeness as C libraries, though the former isn't widely used, and the latter is very experimental still. https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls and https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi respectively.
  - snvzz 3y ago
    wolfSSL is an excellent clean implementation. LibreSSL is the drop-in replacement for openssl that everybody should have embraced back when heartbleed happened.
    - rollcat 3y ago
      > LibreSSL is the drop-in replacement for openssl that everybody should have embraced back when heartbleed happened. 100% and 1000x times this. LibreSSL does have some minor incompatibilities, but those were mostly about removing obscure and very rarely useful APIs that were badly designed in the first place. It was quite likely that if your program used these APIs, it had security issues that OpenSSL couldn't solve with an update. (Usability is security. If it's hard to use correctly, then it's easy to create a security hole.) Remember folks, LibreSSL comes from the same people who made OpenSSH, and that "other" OS that had 2 remote holes in almost 30 years. You already trust them, you maybe just don't know it.
      - jmclnx 3y ago
        I was a bit surprise Linux did not move to LibreSSL when it became stable. IIRC, there was a Linux distro using LibreSSL, but a year or 2 ago the went back to OpenSSL for some reason which I did not fully understand.
        konimex 3y ago
        > but a year or 2 ago the went back to OpenSSL for some reason which I did not fully understand. That would be Void Linux [1]. One of the reasons iirc, is PEP 644 [2], in which CPython drops support for LibreSSL due to it not being fully compatible with OpenSSL 1.1.1 APIs. [1] https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935 [2] https://peps.python.org/pep-0644 https://peps.python.org/pep-0644
        throw_a_grenade 3y ago
        That was either Void Linux (see sibling comment) or Alpine Linux. You might also have read Gentoo Linux announcement (https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.gentoo.org/support/news-items/2021-01-05-libress... ); technically doesn't fit your description since Gentoo never "switched" or "went back", but rather supported them simultaneously, and just pulled support for LibreSSL at some point.
- wbl 3y ago
  OpenSSL is very much part of the problem set here with a long history of dubious API choices, a performance sapping rewrite in 3.0, and many things retained for far too long like VMS support. The problem is that killing it requires a lot of buy-in and dealing with FIPS 140-2 and no one was willing to do that last time.
  - ilyt 3y ago
    The vast majority doesn't need to deal with FIPS garbage. Those can do can make their own security holes for it.
    - wbl 3y ago
      The problem is that if you want Red Hat or Canonical to support integrating your new library across all the applications that need it, it has to support FIPS. If it doesn't people who need FIPS and have the money to support maintenance will avoid integrating it.
- deleted 3y ago
  [deleted]
- stonogo 3y ago
  > It’s effectively one of the only options. Aren't they all one of the only options?
- _V_ 3y ago
  Oh yes, crypto/OpenSSL in C has to be the tenth circle of hell, the one even Dante himself would not dream of in his worst nightmares.

Who is OpenSSL and why do they sell expensive support contracts? It sounds like 1.1.1 is only EOL if you don't pay.

by fh973 3y ago

Who is OpenSSL and why do they sell expensive support contracts? It sounds like 1.1.1 is only EOL if you don't pay.

Isn't that almost always the case with FOSS projects? For instance, throw enough money at Red Hat and I bet they'd support anything you'd like for as long as you'd want.

fh973 3y ago
No, not at all ! It can only be the case of the maintaining entity is the one that sells support. That's actually the definition of commercial software! It may be the case for company-backed FOSS projects (that use FOSS as a marketing channel and have a business model around it). You might be used to that because Redhat, Elastic, Mongo, ... But for very large number of FOSS projects, that's not the case. Either there is no paid support, or it is done by a third-party. But then this third party doesn't call the shots what's deprecated and what's backported where. I was under the impression that OpenSSL is a community project, and now it appears that that's not the case.

aaomidi 3y ago

OpenSSL is the dependency for doing TLS and a lot more. It’s effectively one of the only options. Crypto is hard, and crypto in C is fucking awful. Hence the pricing.

dharmab 3y ago
BoringSSL, wolfSSL, LibreSSL, not to mention the various FIPS options.
- aaronmdjones 3y ago
  ARM mbedTLS is one of my favourites. Excellent documentation.
- TheDong 3y ago
  I think GnuTLS is probably the second most popular TLS library, after openssl. Though actually, maybe, firefox's NSS is now that I think about it a second more. Firefox is at least some fraction of C-library-based ssl traffic out there. I'll also mentions s2n and rustls-ffi for completeness as C libraries, though the former isn't widely used, and the latter is very experimental still. https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls and https://github.com/rustls/rustls-ffi https://github.com/rustls/rustls-ffi respectively.
- snvzz 3y ago
  wolfSSL is an excellent clean implementation. LibreSSL is the drop-in replacement for openssl that everybody should have embraced back when heartbleed happened.
  - rollcat 3y ago
    > LibreSSL is the drop-in replacement for openssl that everybody should have embraced back when heartbleed happened. 100% and 1000x times this. LibreSSL does have some minor incompatibilities, but those were mostly about removing obscure and very rarely useful APIs that were badly designed in the first place. It was quite likely that if your program used these APIs, it had security issues that OpenSSL couldn't solve with an update. (Usability is security. If it's hard to use correctly, then it's easy to create a security hole.) Remember folks, LibreSSL comes from the same people who made OpenSSH, and that "other" OS that had 2 remote holes in almost 30 years. You already trust them, you maybe just don't know it.
    - jmclnx 3y ago
      I was a bit surprise Linux did not move to LibreSSL when it became stable. IIRC, there was a Linux distro using LibreSSL, but a year or 2 ago the went back to OpenSSL for some reason which I did not fully understand.
      - konimex 3y ago
        > but a year or 2 ago the went back to OpenSSL for some reason which I did not fully understand. That would be Void Linux [1]. One of the reasons iirc, is PEP 644 [2], in which CPython drops support for LibreSSL due to it not being fully compatible with OpenSSL 1.1.1 APIs. [1] https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935 [2] https://peps.python.org/pep-0644 https://peps.python.org/pep-0644
      - throw_a_grenade 3y ago
        That was either Void Linux (see sibling comment) or Alpine Linux. You might also have read Gentoo Linux announcement (https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.gentoo.org/support/news-items/2021-01-05-libress... ); technically doesn't fit your description since Gentoo never "switched" or "went back", but rather supported them simultaneously, and just pulled support for LibreSSL at some point.
wbl 3y ago
OpenSSL is very much part of the problem set here with a long history of dubious API choices, a performance sapping rewrite in 3.0, and many things retained for far too long like VMS support. The problem is that killing it requires a lot of buy-in and dealing with FIPS 140-2 and no one was willing to do that last time.
- ilyt 3y ago
  The vast majority doesn't need to deal with FIPS garbage. Those can do can make their own security holes for it.
  - wbl 3y ago
    The problem is that if you want Red Hat or Canonical to support integrating your new library across all the applications that need it, it has to support FIPS. If it doesn't people who need FIPS and have the money to support maintenance will avoid integrating it.
deleted 3y ago
[deleted]
stonogo 3y ago
> It’s effectively one of the only options. Aren't they all one of the only options?
_V_ 3y ago
Oh yes, crypto/OpenSSL in C has to be the tenth circle of hell, the one even Dante himself would not dream of in his worst nightmares.