We have previously talked about our plans for OpenSSL 3.0 and FIPS support
here. This blog
post will give an update about what has been happening since then.
At the Face to Face meeting held on the occasion of the ICMC19 Conference
in Vancouver, a novelty was introduced: For the last day of the meeting all
committers were invited to participate, either personally or remotely via video conference.
As mentioned in a previous
blog post, OpenSSL team members met with various representatives of the FIPS
sponsor organisations back in September last year to discuss design and planning
for the new FIPS module development project.
Since then there has been much design work taking place and we are now able to
publish the draft design documentation. You can read about how we see the longer
term architecture of OpenSSL changing in the future
here and you
can read about our specific plans for OpenSSL 3.0 (our next release which will
include a FIPS validated module)
here.
20 years ago, on the 23rd December 1998, the first version of OpenSSL was
released. OpenSSL was not the original name planned for the project but it was
changed over just a few hours before the site went live. Let’s take a look at
some of the early history of OpenSSL as some of the background has not been
documented before.
The OpenSSL Management Committee has been looking at the versioning scheme that
is currently in use. Over the years we’ve received plenty of feedback about the
“uniqueness” of this scheme, and it does cause some confusion for some users. We
would like to adopt a more typical version numbering approach.
The current versioning scheme has this format:
MAJOR.MINOR.FIX[PATCH]
The new scheme will have this format:
MAJOR.MINOR.PATCH
In practical terms our “letter” patch releases become patch numbers and “fix”
is dropped from the concept. In future, API/ABI compatibility will only be
guaranteed for the same MAJOR version number. Previously we guaranteed
API/ABI compatibility across the same MAJOR.MINOR combination. This more closely
aligns with the expectations of users who are familiar with semantic versioning.
We are not at this stage directly adopting semantic versioning because it would
mean changing our current LTS policies and practices.