The OpenSSL Management Committee (OMC) on behalf of the OpenSSL Project would
like to formally express its thanks to the following organisations
for agreeing to sponsor the next
FIPS validation effort: Akamai Technologies, Blue Cedar, NetApp, Oracle, VMware.
Four weeks ago, the OpenSSL team gathered with many of the organisations
sponsoring the next FIPS module for a face-to-face meeting in Brisbane,
Australia.
We got a great deal accomplished during that week. Having most of
the fips-sponsor organisations in the same location helps ensure that
we are all on the same page for the decisions we need to make going forward.
After two years of work we are excited to be releasing our latest version today -
OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we
are committing to support it for at least five years.
OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been
made from over 200 individual contributors since the release of OpenSSL 1.1.0.
These statistics just illustrate the amazing vitality and diversity of the
OpenSSL community. The contributions didn’t just come in the form of commits
though. There has been a great deal of interest in this new version so thanks
needs to be extended to the large number of users who have downloaded the beta
releases to test them out and report bugs.
Back around the end of 2014 we posted our
release strategy. This
was the first time we defined support timelines for our releases, and added
the concept of an LTS (long-term support) release. At our OMC meeting
earlier this month, we picked our next LTS release. This post walks through
that announcement, and tries to explain all the implications of it.
“That we remove “We strongly believe that the right to advance patches/info
should not be based in any way on paid membership to some forum. You can not
pay us to get security patches in advance.” from the security policy and Mark
posts a blog entry to explain the change including that we have no
current such service.”
At the OpenSSL Management Committee meeting earlier this month we passed the vote above to remove a section our security policy. Part of that vote
was that I would write this blog post to explain why we made this change.
The following is a press release that we just put out about how finishing
off our relicensing effort. For the impatient, please see
https://license.openssl.org/trying-to-find
to help us find the last people; we want to change the license with our
next release, which is currently in Alpha, and tentatively set for May.
For background, you can see all posts in the
license tag.
Note: This is an outdated version of this blog post. This information is now
maintained in a wiki page. See
here for the latest version.
The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new
release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your
application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop
in the new version of OpenSSL when it becomes available and you will
automatically start being able to use TLSv1.3. However there are some issues
that application developers and deployers need to be aware of. In this blog post
I am going to cover some of those things.
At the face to face
last year we discussed future funding models, and we are exploring a range of
possible options. One suggestion raised was we could sell more support
contracts and give those support contract users patches for security issues in
advance.
But before we can even discuss this as an option we would have to change
our public stance. Our security policy since 2014 has stated we would
not do this and currently reads:
The OpenSSL OMC met last month for a two-day face-to-face meeting in London,
and like previous F2F meetings, most of the team was present and we addressed
a great many issues. This blog posts talks about some of them,
and most of the others will get their own blog posts, or notices, later.
Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft
covered the costs of their employees who attended.
One of the overall threads of the meeting was about increasing the
transparency of the project. By default, everything should be done in
public. We decided to try some major changes to email and such.
Today I have had great pleasure in attending the Real World Crypto 2018
conference in Zürich in order to receive the
Levchin prize on behalf of the OpenSSL team.
The Levchin prize for Real World Cryptography recognises up to two groups or
individuals each year who have made significant advances in the practice of
cryptography and its use in real-world systems. This year one of the two
recipients is the OpenSSL team. The other recipient is
Hugo Krawczyk.