This is another update on our effort to re-license the OpenSSL software.
Our previous post in March was about the
launch of our effort to reach all contributors, with the hope that they
would support this change.
So far, about 40% of the people have responded. For a project that is
as old as OpenSSL (including its predecessor, SSLeay, it’s around 20 years)
that’s not bad.
We’ll be continuing our efforts over the next couple of months to
contact everyone.
Of those people responding, the vast majority have been in favor of
the license change – less then a dozen objected. This post describes
what we’re doing about those and how we came to our conclusions. The
goal is to be very transparent and open with our processes.
We announced back in October
that we would be changing from a single OpenSSL Project Team to having
an OpenSSL management committee
and a set of committers which
we planned to expand to enable the greater involvement from the community.
Now that we have in place committer guidelines,
we have invited the first set of external (non-OMC) community members to become committers and
they have each accepted the invitation.
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.
The following is a press release that we just released, with the cooperation
and financial support of the Core Infrastructure Initiative and the
Linux Foundation.
In the next few days we’ll start sending out email to all contributors
asking them to approve the change. In the meantime, you can visit
the licensing website and search for
your name and request the email. If you have changed email addresses,
or want to raise other issues about the license change, please email
license@openssl.org. You can also post
general issues to
openssl-users@openssl.org.
We are grateful to all the contributors who have contributed to OpenSSL
and look forward to their help and support in this effort.
The official press release can be found at the CII website. The rest of this post is a copy:
This post talks about OpenSSL and threads. In particular, using OpenSSL
in multi-threaded applications. It traces through the history, explains
what was changed for the 1.1.0 release, and will hopefully provide some
guidance to developers.
While none of the behaviors have really changed, and therefore none of
this should be new information, the documentation has not been as
clear as it could, or should, be. Therefore, some readers might be
surprised by what’s in this post.
In short, OpenSSL has always, and only, supported the concept of
locking an object and sometimes it locks its internal
objects. Read on for more details.
Last October, the OpenSSL Project team had a face to face meeting.
We talked about many topics but one of them was that, in recent years, we have
seen much more involvement from the community and that we would like to
encourage that further. For example, there are a number of people in the
community who we know and trust. We would like those people to get involved more
and make it easier for them to contribute. We decided to introduce the
concept of a “committer” (borrowed from the Apache concept): someone who has the
ability to commit code to our source code repository but without necessarily
having to become a full team member. This might be seen as a stepping-stone for
someone who aspires to full team membership, or simply as an easier way of
contributing for those that don’t. Those people could help with our review
process (i.e., their reviews would count towards approval) - which might help us
keep on top of the github issues and pull request queues.
The audit took place during 2015 in two phases while the OpenSSL project was
working on the development of the (now released) 1.1.0 version. We chose to
audit the “master” branch of the code as it stood at the time. OpenSSL 1.1.0 has
made some extensive internal changes, most notably in libssl with the new
state machine code, as well as the new packet parsing code. We wanted the audit
team to review that code to give us confidence that what we were delivering was
sound.
I think the most important news here, is that our next release will
include TLS 1.3. Our current plan is that this will be 1.1.1, which means
that it is API-compatible with the current 1.1.0 release. This is really
only possible because of the work we did on making most of the structure
internals opaque. Also, since we are doing all of our work in public on
our GitHub repository, we hope that the entire community will be able to
“follow along at home” and help us improve the code. There will be more,
much more, to say about this later.
Last week, the OpenSSL dev team had another face-to-face meeting.
It was a week of “mosts”: most of the team flew in for most of the
week, and most of it was funded by the
CII/LF
We got a great deal accomplished during that week. We do many things by
vote, and having everyone in the room to talk not only beats email all
to hell, but it ensures that we’re all on the same page for the decisions
we make. Sure, not everything was a unanimous decision, but none
were decided by narrow margins.
In this post I’m going to talk about two important decisions.
Today, Karthik Bhargavan and Gaetan Leurent from Inria have unveiled a
new attack on Triple-DES, SWEET32, Birthday attacks
on 64-bit block ciphers in TLS and OpenVPN.
It has been assigned CVE-2016-2183.
This post gives a bit of background and describes what OpenSSL is doing.
For more details, see their website.