We (the OpenSSL team) are considering a more aggressive EOL strategy. In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes out (currently in beta). Going forward we would only maintain two versions, so when 1.0.3 comes out, 1.0.1 would be EOL. What do people think about this?
On 06/11/14 11:32, Ben Laurie:> Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL.So, the date of EOL of 1.0.1 will not be known. Just some day the 1.0.3 will be released and 1.0.1 become damned. Also, I consider its not so friendly to projects using the OpenSSL. Some of them wish to declare lifetime of particular version at the time of release. It will be possible no longer as embedded OpenSSL may become obsolete at any time. What about ongoing FreeBSD 9.3 release ? According tradition, it's EOL should occur two years past release. But what we will do if embedded version of OpenSSL become unsupported just this winter ? I need to make long term upgrade plans. Not happy with "as OpenSSL declared EOL, your version of FreeBSD has been EOLed as well. Upgrade NOW (or within two weeks - it's no substantial difference for me)" Just my $0.02 ... Dan
Hi, Ben-- Thanks for soliciting feedback. On Jun 11, 2014, at 2:32 AM, Ben Laurie <ben at links.org> wrote:> We (the OpenSSL team) are considering a more aggressive EOL strategy. > > In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes > out (currently in beta). > > Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL. > > What do people think about this?Most folks use the OpenSSL version provided by their OS vendor. OS vendors want to provide long-term support for at least some releases, because many users don't want to chase major version bumps too frequently. (This has strong implications towards ABI stability: even if you EOL 0.9.8 today, vendors will still need to support that for years down the road.) Some advanced users will be more willing to build, deploy, and validate "bleeding edge" versions. Other advanced users are using an OpenSSL version which is baked into the firmware of hardware load-balancers like F5's BIG-IP, Citrix Netscalers, Brocade's ADX, etc. The other group that comes to mind is software developers writing against OpenSSL. I don't want to generalize too far, but even fairly well-known projects like ClamAV who actively use SSL and check cert signing for their virus DB updates are just now starting to implement OpenSSL-0.9.8 functionality like CRL checks _after_ Heartbleed. Regards, -- -Chuck
On Wed, Jun 11, 2014 at 10:32:54AM +0100, Ben Laurie wrote:> We (the OpenSSL team) are considering a more aggressive EOL strategy.> In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes > out (currently in beta).> Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL.> What do people think about this?I appreciate that the OpenSSL team is short on time, but such a change would be rather inconvenient for users. In particular, not only are new OpenSSL versions (like 0.9.8 and 1.0.0) ABI-incompatible, but it is unwise to even install more than one version of OpenSSL on a machine. Because different versions of libcrypto.so and libssl.so provide the same symbols, loading multiple versions into one process may cause a mixture of the versions to be used, which may lead to crashes and other nastiness. To be specific, various libraries and PAM modules in the FreeBSD base such as libarchive, libfetch, pam_krb5 and pam_ssh depend on OpenSSL libraries. Linking an executable to both one of these libraries and ports OpenSSL is a bad idea and may lead to strange combinations like using a 0.9.8 libcrypto with a 1.0.1 libssl and using a 1.0.1 libcrypto from code that wants 0.9.8 except for the symbols that were removed between 0.9.8 and 1.0.1. There are various possible solutions to at least allow installing multiple versions of OpenSSL safely, for easier migration, but none of them in FreeBSD or OpenSSL upstream. This situation is unfortunate, also because OpenSSL is otherwise so close (SSL_CTX object allows multiple independent clients within a process). Various Linux distributions are using a symbol versioning hack submitted in http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest but ignored. FreeBSD supports these ELF features as well. A more portable alternative is renaming all symbols, for example using a huge header file containing lines like: #define SSL_new openssl101_SSL_new #define SSL_free openssl101_SSL_free Yet another alternative is an option for ld to store the DSO ld found a symbol in and have rtld look only in that DSO (and explicit interposers). For the longer term, a stable ABI across versions for the OpenSSL libraries seems an interesting idea (even if only for platforms like FreeBSD and glibc with GNU-style symbol versioning that allows multiple versions of the same symbol). -- Jilles Tjoelker