Those of you have have installed Solaris 11 or have read some of the blogs by my colleagues will have noticed Solaris 11 includes OpenSSL 1.0.0, this is a different version to what we have in Solaris 10. I hope the following explains why that is and how it fits with the expectations on binary compatibility between Solaris releases.
Solaris 10 was the first release where we included OpenSSL libraries and headers (part of it was actually statically linked into the SSH client/server in Solaris 9). At time we were building and releasing Solaris 10 the current train of OpenSSL was 0.9.7.
The OpenSSL libraries at that time were known to not always be completely API and ABI (binary) compatible between releases (some times even in the lettered patch releases) though mostly if you stuck with the documented high level APIs you would be fine. For this reason OpenSSL was classified as a 'Volatile' interface and in Solaris 10 Volatile interfaces were not part of the default library search path which is why the OpenSSL libraries live in /usr/sfw/lib on Solaris 10. Okay, but what does Volatile mean ?
Quoting from the attributes(5) man page description of Volatile (which was called External in older taxonomy):
Volatile interfaces can change at any time and for any
reason.
The Volatile interface stability level allows Sun pro-
ducts to quickly track a fluid, rapidly evolving specif-
ication. In many cases, this is preferred to providing
additional stability to the interface, as it may better
meet the expectations of the consumer.
The most common application of this taxonomy level is to
interfaces that are controlled by a body other than Sun,
but unlike specifications controlled by standards bodies
or Free or Open Source Software (FOSS) communities which
value interface compatibility, it can not be asserted
that an incompatible change to the interface specifica-
tion would be exceedingly rare. It may also be applied
to FOSS controlled software where it is deemed more
important to track the community with minimal latency
than to provide stability to our customers.
It also common to apply the Volatile classification
level to interfaces in the process of being defined by
trusted or widely accepted organization. These are
generically referred to as draft standards. An "IETF
Internet draft" is a well understood example of a
specification under development.
Volatile can also be applied to experimental interfaces.
No assertion is made regarding either source or binary
compatibility of Volatile interfaces between any two
releases, including patches. Applications containing
these interfaces might fail to function properly in any
future release.
Note that last paragraph! OpenSSL is only one example of the many interfaces in Solaris that are classified as Volatile. At the other end of the scale we have Committed (Stable in Solaris 10 terminology) interfaces, these include things like the POSIX APIs or Solaris specific APIs that we have no intention of changing in an incompatible way. There are also Private interfaces and things we declare as Not-an-Interface (eg command output not intended for scripting against only to be read by humans).
Even if we had declared OpenSSL as a Committed/Stable interface in Solaris 10 there are allowed exceptions, again quoting from attributes(5):
4. An interface specification which isn't controlled
by Sun has been changed incompatibly and the vast
majority of interface consumers expect the newer
interface.
5. Not making the incompatible change would be
incomprehensible to our customers.
In our opinion and that of our large and small customers keeping up with
the OpenSSL community is important, and certainly both of the above
cases apply.
Our policy for dealing with OpenSSL on Solaris 10 was to stay at 0.9.7
and add fixes for security vulnerabilities (the version string includes the CVE numbers of fixed vulnerabilities relevant to that release train). The last release of
OpenSSL 0.9.7 delivered by the upstream community was more than 4 years
ago in Feb 2007.
Now lets roll forward to just before the release of Solaris 11 Express in 2010. By that point in time the current OpenSSL release was 0.9.8 with the 1.0.0 release known to be coming soon. Two significant changes to OpenSSL were made between Solaris 10 and Solaris 11 Express. First in Solaris 11 Express (and Solaris 11) we removed the requirement that Volatile libraries be placed in /usr/sfw/lib, that means OpenSSL is now in /usr/lib, secondly we upgraded it to the then current version stream of OpenSSL (0.9.8) as was expected by our customers.
In between Solaris 11 Express in 2010 and the release of Solaris 11 in 2011 the OpenSSL community released version 1.0.0. This was a huge milestone for a long standing and highly respected open source project. It would have been highly negligent of Solaris not to include OpenSSL 1.0.0e in the Solaris 11 release. It is the latest best supported and best performing version.
In fact Solaris 11 isn't 'just' OpenSSL 1.0.0 but we have added our SPARC T4 engine and the AES-NI engine to support the on chip crypto acceleration. This gives us 4.3x better AES performance than OpenSSL 0.9.8 running on AIX on an IBM POWER7. We are now working with the OpenSSL community to determine how best to integrate the SPARC T4 changes into the mainline OpenSSL. The OpenSSL 'pkcs11' engine we delivered in Solaris 10 to support the CA-6000 card and the SPARC T1/T2/T3 hardware is still included in Solaris 11.
When OpenSSL 1.0.1 and 1.1.0 come out we will asses what is best for
Solaris customers. It might be upgrade or it might be parallel delivery of more than one version stream. At
this time Solaris 11 still classifies OpenSSL as a Volatile interface, it is our hope that we will be able at some point in a future release to give it a higher interface stability level.
Happy crypting! and thank-you OpenSSL community for all the work you have done that helps Solaris.
