Steve Marquess is leaving the OpenSSL project as of the 15th of November 2017.
The OpenSSL Management Committee (OMC) would like to wish him all the best for the future.
All communication that used to go to Steve Marquess directly, should now be sent to info@openssl.org in the first instance.
Thanks for your contributions to the project over the years!
For as long as I have been involved in the OpenSSL project there has been one constant presence: Steve Henson. In fact he has been a part of the project since it was founded and he is the number 1 committer of all time (by a wide margin). I recall the first few times I had any dealings with him being somewhat in awe of his encyclopaedic knowledge of OpenSSL and all things crypto. Over the years Steve has made very many significant contributions both in terms of code but also in terms of being an active member of the management team.
We had been invited to spend time with the open source community in China by one of the developers - Paul Yang - who participates in the OpenSSL project. A number of the team members had communicated via email over the last year and when the suggestion was made there were enough of us willing and interested to visit China for a “tour” to make sense. So the tour was agreed as a good thing and that started the journey that lead to spending a week in China (last week as I write this on the plane on the way back to Australia).
We’ve had a change in the stakeholder aspect of this new FIPS 140 validation effort. The original sponsor, SafeLogic, with whom we jump-started this effort a year ago and who has worked with us since then, is taking a well-deserved bow due to a change in circumstances. Supporting this effort has been quite a strain for a relatively small company, but SafeLogic has left us in a fairly good position. Without SafeLogic we wouldn’t have made it this far, and while I don’t anticipate any future SafeLogic involvement with this effort from this point on, I remain enormously grateful to SafeLogic and CEO Ray Potter for taking on such a bold and ambitious venture.
The next release will include a completely overhauled version of the random
number facility, the RAND API. The default RAND method is now based
on a Deterministic Random Bit Generator (DRBG) implemented according to
the NIST recommendation 800-90A.
We have also edited the documentation, allowed
finer-grained configuration of how to seed the generator, and updated
the default seeding mechanisms.
There will probably be more changes before the release is made, but they should be comparatively minor.
Read on for more details.
It’s been almost a year since plans for a new FIPS 140 validation were first announced. Several factors have led to this long delay. For one, we chose to focus our limited manpower resources on higher priority objectives such as the TLS 1.3 implementation. SafeLogic has also experienced difficulties in obtaining the funding for their intended sponsorship; potential sponsors can contact them directly.
With TLS 1.3 now done (pending only a final TLS 1.3 specification) we’re now in a position to turn our attention to the new FIPS module, and just in the nick of time Oracle has pledged enough funding to get us off to a good start. With financial support from the Linux Foundation Core Infrastructure Initiative temporarily interrupted, leaving a team member with no income, that funding eases the pressure to seek new long term employment.
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: