4 ms·

If you ever statically link OpenSSL, your binary now has a builtin expiration date. You are doing your users a disservice.

• marcosdumay 5y ago
  To be fair, if you dynamically link to OpenSSL, your binary has a builtin expiration date too, and it's very likely the same date.
  • nly 5y ago
    OpenSSL ABI has been fairly stable within a given series. Something compiled against 1.1.0a (Sep 2016) has a fair chance of running on a system that has 1.1.0l (Aug 2021). 5 years of binary compatibility is nothing to be sniffed at for a C library. https://abi-laboratory.pro/index.php?view=timeline&l=openssl https://abi-laboratory.pro/index.php?view=timeline&l=openssl
    • marcosdumay 5y ago
      Funny because I've seen incompatible changes twice on this timeframe. The last one I remember. It was moving the API that did version negotiation from recommended to deprecated and then removed status. But yeah, the API itself didn't change. All that changed is the recommended way to interact with the library, and the old one removed.
    • iggldiggl 5y ago
      The last release of IMAPSize e.g. dates from 2009 and can no longer connect to some IMAP servers that presumably don't support older SSL/TLS-versions, but by replacing the OpenSSL-DLLs with a recentish versions, everything works fine again.
  • AshamedCaptain 5y ago
    Not really. I have made updated versions of libSSL that allow use of new ciphers with the old ABI, for example. (Retro purposes). But for example this has been done to extend the life of other binary-mostly platforms (e.g. webOS). As long as I can change libSSL separately, this is trivial.