Openssl

[Jason W]

With openssl, any update requires that all packages that are built against it be recompiled.  There are over 50 extensions last time I counted that use openssl.  I have no intention of forcing an openssl update and a recompile of it's dependent extensions, even as part of a major TC version upgrade when that time comes. 

What I am planning is to make an openssl extension that is self contained under /usr/local/openssl-1.0.0(/bin,/lib,/etc) when version 1.0.0 is stable.  Then anyone who wants to use the newer openssl can compile against it and use a wrapper script so the apps can find the ssl libraries.   And those newer libs won't be found by ldconfig so they won't interfere with the current openssl libraries in the system.  Wrappers were used a lot with the .uci extension type that was installed into /opt and had supporting libs packed in with the extension. 

There are several approaches that can be considered when building apps with ssl support. 

1.  Use the existing extension installed into /usr/local that is recognized by ldconfig.  This version I think should remain at 0.9.8h from now on to support the many existing ssl enabled extensions. 

2. Make use of the shared libraries of an updated extension installed self contained into /usr/local/openssl-$version and use wrapper scripts to make use of those libs.  That is, when it becomes available.   This is what I plan to do eventually with my own ssl apps.

3.  Compile ssl support statically into an app.  Though this makes the extension larger, it makes it independent of needing openssl libraries installed in the system.  And the latest available version of openssl can be used to do this regardless of openssl extensions available. 

4.  Include your own build of openssl libraries with your extension, self contained in a directory that is not found by ldconfig so as to not interfere with the current ssl extension and use a wrapper to find the libraries.  Though not space saving as the ssl libs would be included with each extension, this also lets you use the latest and greatest ssl.


Though we now use a modular, shared library approach to extensions and normally use standard install paths, I think openssl is one where we may be better in the long run to consider an approach that will not require a rebuild of apps and allow a smooth transition to a newer openssl version. 

[Jason W]

The recent python update, as well as some reading on some security advisories on openssl prompted me to consider it's eventual updating.   Openssl was one of the first extensions made last summer, and hindsight is always 20/20.   I am not going to update the openssl that installs into /usr/local as that would force the rebuild of tens of extensions.  That is unless there is a good argument for doing so. 

Openssl 1.0.0 should be released soon, and when that happens I will make an extension that installs into /usr/local/openssl-1.0.0 so as to not interfere with the version in /usr/local.  Most apps have a configure swich like --with-ssl=/path/to/dir that makes building against openssl in it's own directory easy. 

If one wants to always use the latest version for their apps, they can use choice number 3 or 4 mentioned above.

[bmarkus]

Openssl 1.0.0 should be released soon, and when that happens I will make an extension that installs into /usr/local/openssl-1.0.0 so as to not interfere with the version in /usr/local.  Most apps have a configure swich like --with-ssl=/path/to/dir that makes building against openssl in it's own directory easy. 

I wouldn't update to 1.0.0 but would wait for 1.0.3 or something. Usually such a major change is buggy... Just a thought, nothing against openssh

[Jason W]

With the question of which version to use, along with the fact that it would not be current for long, has me leaning towards encouraging static ssl builds to allow each extension maker to use the latest version.  Having openssl to be used as shared libs would not be feasible to keep current without multiple version littering the repo. 
One idea may be to have an openssl-current extension that is always the latest stable version.  It can be used to build against, statically or shared.  If one wants shared ssl libs, they would need to pack them in with the extension and use a wrapper.  That may be better than having one openssl version that does not change for a a half a year or more to build against though it does not save as much space. 
The more I think of it, keeping a current openssl extension is desirable, and then leave it to each extension whether they want to do a static build or copy the shared libs to the extension in a directory not found by ldconfig.  It is not the most space saving but it solves all the issues around using a current openssl.

[Jason W]

Upon much reading and consideration, I am going to install openssl-0.9.8k into /usr/local/openssl-0.9.8k and submit it.  I have read that there is supposed to be binary compatibility between the 0.9.8x versions, but I have also read of apps breaking between patchset upgrades.  While it may be safe to use the same certs directory, I have also read of certs not working between versions.  So openssl gets installed totally into its own directory to avoid any potential problems.  Certs are to go in /usr/local/openssl-0.9.8k/etc/ssl which will be documented. 

What I am not sure about is the feasibility of chasing the latest version.  Most openssl vulnerabilities apply to using openssl as openssl, not as a shared library.  I am sure most folks here, like myself, use openssl mainly as a shared library.  And as version 0.9.8k is the latest and is mature, I think it would be a keeper for at least the rest of this year.  That will give time to think about the structure of future upgrades. 

Not chasing the latest version will allow a particular ssl to build against and make use of it's shared libs as the shared libs weigh in at about 1.5mb which would really add up if each ssl enabled extension had to contain those libs.

[Jason W]

I will wait for the stable release of 0.9.8m as that will be about one year since 0.9.8k.  And it will install into it's own directory like 0.9.8k did.

[Jason W]

We are using 0.9.8m now and all seems well.