- 1 OpenSSL (SSL and Crypto) libraries
- 1.1 Description
- 1.2 List of apps and libraries using this library
- 1.3 API documentation
- 1.4 Licensing
- 1.5 Related test suites
- 1.6 Library analysis data
- 1.7 OpenSSL versions in distributions
- 1.8 OpenSSL stability analysis
- 1.9 Potential Issues
- 1.10 Other Information
OpenSSL (SSL and Crypto) libraries
The OpenSSL candidate is a toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library.
This candidate is being tracked as #022 on the futures candidate tracker.
List of apps and libraries using this library
- kdelibs (futures candidate, being discussed)
- openssh (and other ssh tools, these too are future candidates.)
- Desktop Mail applications (generalising, as all specific mail applications inside lsb are yet to be identified: FIXME)
- [attachment:LICENSE_openssl.txt License] - Apache Style allowing both Source and Binary distribution
- Legal Issues on inclusion with GPL software
- GPL clause allowing OpenSSL - follow the thread for RMS's suggestions on the same.
Related test suites
- in-built test scaffold available on make test
Library analysis data
!ChangeLog indicates minor changes in exported API between successive subversions. 0.9.7a -> 0.9.7h indicate fewer changes, while 0.9.7h -> 0.9.8 show deprecated API being removed.
OpenSSL versions in distributions
|SUSE Linux Enterprise Desktop 10 (i586)||openssl-0.9.8a-18.4|
|Red Hat Enterprise Linux Client release 4.91 (Tikanga)||openssl-0.9.8b-5|
|Ubuntu 6.06 LTS||0.9.8a-7build1|
|Mandriva Linux release 2006.0 (Official) for 586||openssl-0.9.7g-2.1.20060mdk|
|Red Hat Desktop release 4 (Nahant Update 3||openssl-0.9.7a-43.8|
This documents methods and data used to identify a potential OpenSSL API subset for LSB inclusion.
- Run time random number generation depends upon operating system provided /dev/urandom /dev/random or egd daemon. Without these services it might be possible to produce a LSB compliant binary that behaves differently at runtime (OpenSSL 0.9.7 and above appear to cause an abort if the system does not supply a source of randomness and the application does not itself provide random data).
- Legal issues (both civil 'patent issues' and criminal 'is crypto even legal locally?') surrounding crypto in general make it hard to determine what algorythms can practically be used in a global context due to varrying national policies towards cryptography.
- Programming style greatly impacts the level of ABI compatibility. If structures are treated as opaque types by the application, far greater ABI compatibility can be achieved. However, possibly for historical and legacy reasons, SSL allows many types to be publically available. It may not be possible to create a highly sophisticated OpenSSL application without using full type information since not every detail of the library is available through accessor functions, however the common case appears to be well covered with accessor functions.
GnuTLS is preferred by some packagers as a suitable alternative as there are No Patent related issues and the package is licensed under LGPL. Debian package and legal advisors are urging (upstream) package maintainers to switch to GnuTLS to get more packages and libraries that are GPL compatible.
- At least one person - Paul Mackay has asked for a review on GnuTLS vs openssl although he seemed very reasonable in admitting that openssl was being adopted as it was de facto being used by many distributions. There are two replies to his mail on the list (as there are no other addressing the openssl candidate on the list as is), one from Pradosh, and one much later by me (Beta).
- one very popular package Gaim depends on GnuTLS. Maybe we need to introduce this as a separate candidate in that case.
YetAnotherSSL is dual licensed. It is doubtful whether this would ever fit the licensing criteria even if the features were found usable.