An update in July, 2016, changed the way Allegro CL interfaces with OpenSSL libraries. Prior to the update, an OpenSSL library was built into one of the Allegro CL libraries included in the Allegro CL distribution. This made using OpenSSL in Allegro CL easy but it meant that users had to wait for an update from Franz before a newer update of OpenSSL could be used. (Allegro CL currently only supports OpenSSL version 1.0.1 and its updates. Support for that version will end on December 31, 2016. By that time, Allegro CL will be updated to support for OpenSSL 1.0.2.)
This was not very satisfactory, either form Franz's or the customer's point of view. OpenSSL updates come out regularly. Because they are related to security, users, particularly those delivering applications, want to have the latest update, but there was always a delay between an OpenSSL update being released and the corresponding OpenSSL/Allegro CL update. And further, the new update could not be simply dropped into an Allegro CL application at the application user's site. The developer would have to make a new release and distribute it to the users.
So the system was changed to always use the latest version on the machine on which Allegro CL was running. But this change introduced a new problem: how to find this latest version. On some platforms, OpenSSL is included with the OS and put in standard locations and is, thus, easy to find. On others, OpenSSL is installed separately from the OS and its location is not standard.
It is even more complicated for delivering applications because the setup on an application user's machine may be quite different from that on the application developer's machine.
To address these problems, we made some changes in the way the OpenSSL libraries were searched for compared to how other foreign libraries used by an application are searched for. What Allegro CL normally does with foreign libraries is remember their names and then load them on start up, looking for them in the application directory or in the directories specified by LD_LIBRARY_PATH. The problem with OpenSSL libraries is the names change, and may be quite different on different machines (with more than the final version number changed). Application writers could copy the OpenSSL library from their machine into the application distribution, thus guaranteeing it would be found when the application was run, but that would mean the application developers would inherit the problem Franz is trying to avoid: constant updates.
OpenSSL libraries are now looked for afresh each time Allegro CL or an Allegro CL application starts up. OpenSSL libraries are discussed in the Secure Socket Layer (SSL) section in socket.htm. The algorithm for finding the OpenSSL libraries is given in The algorithm for loading the OpenSSL library in that same document. The algorithm is platform-dependent. On systems like the Mac, FreeBSD, and Solaris, where OpenSSL is part of the OS, Allegro CL depends on the system loaded doing the right thing. On Windows and Linux, there is a varaible which can be set and a new environemnt variable ACL_SSL_LIBRARY_NAMES.
Getting the loading of OpenSSL libraries right is one of those bookkeeping tasks that is occasionally difficult at first but once it is working, it usually continues working without problem. Application developers are urged to test their applications on platforms and, if possible, networks separate from their development machines to ensure OpenSSL loading succeeds.
|Copyright © 2017 Franz Inc., All Rights Reserved | Privacy Statement||