This means that there are far fewer support issues caused by the libraries installed on the server that EZproxy is being run on. These can be caused by differences between Linux distributions, new releases of a Linux build with different library versions, 32-bit vs 64-bit versions, etc.
This reduced support load comes at a cost, however. As end users, we are at the mercy of OCLC to release updates for bugs/issues in underlying support libraries.
By releasing a dynamically linked version of EZproxy, the software will be using the library files on the server, rather than the one built into it when the software was built for release.
For example, any issue in the OpenSSL libraries may go unresolved for months between EZproxy releases, while the OS vendor may have an updated library released within days.
For reference, other 3rd party libraries that EZproxy build into the static binary include the GNU C Library, MaxMind's GeoIP, OpenLDAP, a XMLSec library, a XPath/XSLT library, what looks like a HTML parsing library, most likely a SOAP library, a SAX parser, a Kerberos library, and maybe a few more that I missed.
That list may be daunting, but in reality, I suspect that all of those libraries are available in any modern Linux distribution out of the box. Of course with a properly packaged software build, they could incorporate requirements and all of this would be installed automatically by the system's software management tools.
As a side note, even if they do not release a dynamically linked binary, OCLC should at least change the way they communicate releases:
- Be more open about what libraries and versions of libraries a given release incorporates
- When an supporting library is updated note any CVE references fixed in the newer library version
- Differentiate between when a security fix was due to a supporting library vs. when a fix was in EZproxy itself.
No comments:
Post a Comment