which openssl should I use?

[jls]

Hi
I'm updateing sylpheed, which openssl should I use?

[bmarkus]

Hi
I'm updateing sylpheed, which openssl should I use?

Depends on. You can use 0.9.8 as before to use shared libs.

Compiling against 1.0.0 your application will use a static 1.0.0 built into your app resulting bigger code but it will not depend on shared 0.9.8

If you are not maniac on 1.0.0 then 0.9.8 will do the job.

[Jason W]

I am still pondering what upgrade approach we should use with openssl.  Here are the options I see at this point.  The openssl 1.x installed into a non standard path is temporary to provide 1.x for those who want to build against it.

First would be to start from scratch and rebuild everything at the start of a new TC release cycle, the next one (TC 5.x) would likely be a candidate. 

Second would be to place a shared openssl-1.x in the standard path, and deprecate openssl-0.9.8.tcz and create a libssl-0.9.8 extension that would simply contain the two shared libs needed by apps that depend on them - /usr/local/lib/libssl.so.0.9.8 and /usr/local/lib/libcrypto.so.0.9.8.  Then we could gradually move away from 0.9.8, building all new stuff with openssl-1.x.  Red Hat uses an openssl compatibility package that does this similar thing to provide for an openssl dependency that is different from the standard installed version.

Third would be to have the libssl-0.9.8 extension as above to provide those two libs for existing stuff, and have a static openssl-1.x installed into the standard path to build against.  New ssl dependent extensions would not depend on the openssl-1.x extension during runtime.  And 0.9.8 would be slowly phased out.

The first approach would seem to be a lot of lost extensions and mass rebuilding all at once upon a major openssl update.  The second approach is better, but could leave us in a constant state of transition with two openssl versions available.  By the time we weed out the old version, a new one would be available to start moving to.  Though it would have the extension size and memory requirement savings of the shared lib approach.

My own personal preference would be that of the simplicity and sustainability of having a static openssl installed to the standard /usr/local path so it is easy to build against.  That would allow us to always keep the latest openssl extension, and once 0.9.8 is phased out, there would be only one version of openssl or its libs in the repo.  How much an extension gains size by statically linking to openssl varies upon how much openssl it needs, I think the cost in extension size is worth the benefits and lack of headaches that other openssl update approaches would give.  With the concepts of ondemand and loading what you need when you need it as the normal use of TC, a modest gain in extension size I don't see as a deal breaker.

There is plenty of time to consider the approach we will eventually take, but I do lean toward the static ssl.

[Jason W]

We don't have to act now, but I am curious of what our main extension makers think on this.  Should we continue to build new, latest and greatest apps against the aging openssl 0.9.8 in the meantime, creating more of a burden for the eventual upgrade?  Or should we go ahead and adopt an approach that will wean us off of 0.9.8 while ensuring no future mad rush of rebuilding is needed (ie, using either static or shared openssl in standard path while providing a legacy libssl-0.9.8.tcz for the two lib files to support current dependent apps.)?

Again, no need for immediate action.  But perhaps in the long run we may benefit from going ahead and putting it on the table.  I want to know what folks think, even if it is "better to stay put for now". 

[bmarkus]

Migration must be smooth.  Due to the nature of community model you must keep shared libs as it is till last extension is available in repo. Question how are they updated or rebuilt in the future.

During last gnutls update I moved to static 1.0.0 wich works fine but of course size increased.

What is about to provide 1.0.0 shared libs with non standard path? In such case new extensions built against 1.0.0 and coexist with current extensions.

[Jason W]

An openssl-1.0.0 in the standard path is definitely the planned upgrade, so it would be easy to build against.  And a libssl-0.9.8 that contains 2 files ( /usr/local/lib/libssl.so.0.9.8 and /usr/local/lib/libcrypto.so.0.9.8 ) will take care of the dependency of existing apps.  I searched the ldd output of all the files in all the extensions and none are linked to libssl.so or libcrypto.so, only libssl.so.0.9.8 and libcrypto.so.0.9.8.  So there will be no conflict with an openssl-1.0.0 extension, and during new builds nothing should get accidentally linked to one of the 0.9.8 libs.

We did once try a 0.9.8k extension that was shared and in a non standard path, and the resulting builds would not find the libs since they were not in the standard path.  It would require using a wrapper script.

I think it would be best to keep it in the standard path, the question being static vs shared.

I lean toward static, as though it would increase extension size by a variable amount, we would never again have to even discuss an upgrade.  As all new extensions would be built against the latest openssl release.  And we could keep the 0.9.8 libs around for as long as needed by old extensions with no pressure to deprecate them. 

With a shared openssl-1.0.0, we would one day again be discussing how to upgrade and there would eventually be pressure to rebuild or remove things that depend on 0.9.8.  We would have the advantage of smaller extension sizes, but we could not keep a current openssl around but instead a fixed version as before.

I would like to create a current static openssl extension in the standard path which could be always kept current, and move the needed libs from the 0.9.8 version into a libssl-0.9.8.  I will test this scenario to make sure it is as easy to build against as the current shared 0.9.8 extension is and with no unexpected results.

I am open to further considering the shared lib approach, though I don't think the benefits outweigh the potential down sides mainly in regards to future upgrades.

[bmarkus]

Using shared libs is the common way through applications. What happenes when 1.0.1 is released? Rebuild for example gnutls with the new 1.0.1 static. If it would be shared, no need to rebuild gnutls and others. I do not know how often openssl expected to be updated. If applications are more frequently, it is not an issue.

In general I do not like static builds, but it is my private issu

[Jason W]

I agree that shared libs is normally best, as it would be insane to static build gtk2 and deps into every gtk2 extension. 

When openssl-1.0.1 is released, then if we are using a shared 1.0.0 extension, we simply are stuck with 1.0.0 as it is only compatible with lettered point releases (1.0.0a is compatible with 1.0.0e, but not with 1.0.1 for example). Or we would have to embark on yet another migration, away from 1.0.0, making a libssl-1.0.0 extension to satisfy existing apps and creating a openssl-1.0.1 extension. 

With as much effort that goes into keeping most apps up to date, a static openssl would allow each update to use the latest openssl.  A shared openssl would leave us stuck with a particular openssl version for a long time, regardless how up to date the dependent app is kept. 

Openssl seems to update it's number release every couple years, but we have been using 0.9.8 for almost 3 years now, and it will be a long time before we will be able to retire it.  Extensions seem to definitely be updated more often than openssl number upgrades.  We can think about it further, but I like the idea of keeping a current openssl, and  never having to migrate again unless one takes the option of rebuilding against openssl when it is updated.

[bmarkus]

I guess all aspects discussed. Highest priority not to break current repo and applications. As an extension maker, I'm fine with static 1.0.0 build. When build script adjusted, no difference rebuild against shared or static openssl.

Seems that static 1.0.0 build when ever is possible updating extensions is a good way, I vote for this way.

[Jason W]

Ok, I will start testing to make sure that the presense of the 0.9.8 shared libs does not cause conflict or unexpected linking when building against a static 1.x in the standard path.

[Jason W]

On doing some test builds, all seems well.  The only question that remains then is when to make the move.  Do we want to go ahead, or wait until TC 5.x?  The dep files will be adjusted like this:

openssl-0.9.8  ->  libssl-0.9.8

openssl-0.9.8-dev  ->  openssl-1.0.0-dev

The runtime of apps should remain unaffected.  And the dep files of the -dev extension is what will rebuild the extension, so the current openssl-dev should be in those cases.  Though an extension being rebuilt against the new openssl may have dependencies that was built with the old 0.9.8, that should not affect the building of the new extension, since it is that new build will draw it';s ssl stuff from openssl and not it's dependent apps.

If this sounds like it will not cause too much confusion, we can go ahead and make the dep file changes.  Otherwise it won't hurt to wait until TC 5.x.

[Jason W]

Being no protest and it all should go smoothly, I have uploaded libssl-0.9.8.tcz and openssl-1.0.0.tcz, openssl-1.0.0-dev.tcz.  Doing the below should make for a smooth transition for those with existing tce directories"


Go to Appsaudit and do "update dep files"
Go to Appsaudit and do "fetch missing dependencies"
Go to Appsaudit and select openssl-0.9.8.tcz and do "mark for deletion"
Go to Appsaudit and select openssl-0.9.8-dev.tcz and do "mark for deletion"

Reboot.

Then install openssl-1.0.0.tcz for openssl functionality.  The libssl extension will take care of dependent apps library needs.  The dev extensions that depended on the openssl-0.9.8-dev will now depend on openssl-1.0.0-dev as there will be no more openssl-0.9.8-dev, but replaced by openssl-1.0.0-dev.  The existence of the old 0.9.8 libs in libssl should not interfere with building against the new 1.0.0.  Let me know if there are any concerns.

[floppy]

I deleted " openssl-0.9.8.tcz" yesterday and could not startX in mc4.0.2 and Xorg7.4.
So, I had to put it again in the extensions.

[Jason W]

I am assuming you have libssl-0.9.8.tcz installed and loaded before Xorg?

[Jason W]

There may be some apps that require the openssl command, that would be satisfied by the openssl-1.0.0.tcz extension while the library linking is taken care of by libssl-0.9.8. I will look more into it when I get home.