Press Coverage

There have been more articles written based on the interviews with Paul Yang from BaishanCloud, Tim Hudson, and Steve Marquess from the OpenSSL team.

• AQNIU
• TechTarget
• ScienceNet

These join the articles noted in the previous blog entry.

• FreeBuf
• Leiphone
• iTuring Press

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).

What started out as a quick visit to one company rapidly turned into a multi-city, multi-company event - with a mixture of:

• see “China”
• visit major companies that use OpenSSL
• meet with developers who work with or contribute to OpenSSL
• a half-day presentation session with open source developers at which each member of the OpenSSL team would speak on a different topic.

Our hosts BaishanCloud put an amazing amount of effort into organising the trip - everything was planned for - from the flights, the hotels, who would meet as at the airport and what signs they would hold and what they looked like and their contact details. Nothing was left to chance.

Our arrival day came and into Shanghai flew the five of us (Matt, Richard, Steve, Tim, and finally Rich) spread out over the day and across multiple airlines and terminals. Despite the logistical challenges the BaishanCloud team made the arrival a very smooth process.

We stayed in fantastic hotels, and at each stage we had a designated guide (from the marketing team) that looked after the logistics. For Shanghai and Hangzhou it was Jane, for Shenzhen it was Shirley, and for Beijing it was Alan. We learned rapidly to simply follow their lead as everything had been planned - even the unexpected.

Paul (Yang Yang), Sean, and Jedo from the BaishanCloud engineering group also accompanied us everywhere. It was great to have the company and be able to interact over the whole trip. Their backgrounds were as different as their personalities and their individual sense of humour.
We spent a lot of time together over the week - from early starts (for the engineers) at 7am for breakfast - to late nights discussing the day, plans for the next and getting to know each other (after 10pm) - we simply kept on-the-go all the time.

Woven through the complex schedule were tours of some famous Chinese locations - Lingyin Temple in Hangzhou, Shenzhen Sarafi Park in Shenzhen, Imperial Palace / Forbidden City and Shichahai Lake in Beijing.

Our hosts did not just want us to visit people - they wanted us to experience some part of the wonderfully rich history of the Chinese people - a detailed history that goes back far beyond the recorded history of countries that we all came from.

We had many adventures along the journey but we all experienced a lot of things. As a team, we discussed the various different things from architecture, traffic, cars, culture, working hours, city layout, food, social customs, and the prices of various items. It was amazing for me to see the difference between the team members and their own cultural experiences and viewpoints changing what was seen. Those of us who had travelled and experienced other cultures simply soaked it all in and appreciated the depth and complexity of the uniquely Chinese experiences.

Discussions over dinner about the rich experience made it very clear that we saw different aspects of the experience of this deeply unique culture.

Our Hosts

Our hosts also had their own preconceived notions of what the team would like - would we be able to eat the food - could we use chopsticks (we all can and even those who had only minimal experience with chopsticks used them at every lunch or dinner), - could we eat the food (given how foreign it would be). Some of us are definitely more adventurous than others (sticking to mild food that was more familiar) but most of us eagerly tried the huge range of dishes that our hosts provided. Almost every meal we had to say “stop, no more food” as the dishes kept coming out - and with each new dish we wanted to try it - but the stomach can only fit so much food despite how interesting and tempting the dish was. It was a testament to the range of food experiences that we had that for many of the dishes we ate our engineering hosts had themselves never eaten.

By the end of the week, we all recognised many of the dishes, had definite personal preferences, and all could easily pick up individual grains of rice with chopsticks and eat without making too much of a mess on the table. Still, even at the final traditional Chinese meal together we still were exposed to dishes we hadn’t eaten before and more food then we could possibly eat. There were also concerns about whether or not we would understand their English (not a problem) - and although we had some very funny moments figuring out what some things, there was never moment where we couldn’t figure out how to communicate. Sure there are lots of strange words and phrases we use that added to the fun - but basic communication simply isn’t a problem.

The monkey riding on a chicken

One phrase that does stick in the mind is how our guide (Snow) to the forbidden city explained things in ways she knew we, as foreigners, would remember - pointing to the roof of a building she said “see what looks like a monkey riding on a chicken - that’s an immortal on a phoenix leading the procession of mythical creatures”. We saw that “monkey-riding-on-a-chicken” a lot during our time in the forbidden city. Little things like that helped frame the cultural reference and had us looking for the markers - noticing which buildings were associated with the emperor and which buildings were temples - and how important each of the buildings were relative to each other (counting the mythical creatures became second nature to fitting the importance of each building into context).

There is also a clear distinction in the Chinese people we interacted with between those who are immersed in the traditions and culture and those who are much more focused on the future. We all experience that in our own cultures and it was refreshing to see the full range of viewpoints. Some of our hosts have never before visited or experienced what was being shown to us, and we got to see how they reacted to the experience - and as expected, different things caught their interest and we had many discussions about the experience of the day over dinner each evening.

China Is Simply Not Just The Same As Back Home

We are a team, and like all teams we are made up of individuals who had very different experiences. We are shaped by our experiences and the willingness to be open to new experiences without mapping them back in term of our own cultural context is absolutely critical to getting a rich experience when learning about other cultures.

China is different (as are all cultures), Chinese engineers have different obstacles to overcome to participate in open source projects - obstacles that we as a team should be actively aware of and looking to reduce.

China’s Open Source Leaps

Open source has revolutionised China software engineering - and that open source has allowed a new generation of companies to take an amazing leap forward - with the building blocks freely available anyone with an idea and passion can turn that idea into a business - staffed from a huge pool of engineering talent - and be successful. There are innovations and engineering going on in China that equal or exceed the engineering achievements elsewhere in the world - that was clearly evident in the meetings we had with staff at various companies - from small start-ups through to massively successful major brand names.

Very few companies in the world are pure open source companies - there are unique challenges to making a successful living as an “all-open-source” company. For most companies, it is easy to import or adopt open source, it is much more difficult to contribute back to open source. The same is true in China. Getting the balance right for a company requires education and commitment from both engineering and executives in order to ensure that the benefits are understood along with the appropriate protections being in place so that the company only contributes what it expects to contribute. The concept of contribution back to the open source community is clearly at an earlier stage in China than it is in the counties of the OpenSSL team members.

How to grow this realisation is something we will be discussing further - and this goes wider to the entire open source community and it not something specific to OpenSSL.

Typical Chinese Engineering Work Days

Chinese engineers generally live a long way from the office (1-2 hour or longer journeys are common) and have to come into the office (it is rare to be able to work from home) and stay late in evening. Ending at 9pm is common. And catching up with friends and a social life seems to start around 10pm. Getting a 2am WeChat message is considered normal - nothing at all strange.

It wasn’t unusual for our host to have a full day’s work (full from our typical western point of view) and then after making sure we were heading to sleep in our rooms to then head out to catch up with friends and colleagues from the companies we had visited during the day. And then the next morning have to be up again early (very early from a Chinese engineer perspective) to make sure we had breakfast and were ready for the bus ride to whatever our destination was for the first visit of the day

Chinese Company Exhibits

The larger companies that we visited all have exhibition areas to show visitors what the company does (and how successful the company is). The larger the company the more focus there was on packing in maximum information into the exhibits. Having 20 separate displays was not unusual. These exhibits were clearly designed for both a Chinese audience and an English audience.

How many products, customers, engineers, and how much revenue and what problems the company products solve were on proud display. It was very interesting watching the reactions of the other team members who clearly hadn’t internalised the size and scope of China or the technical developments and achievements of Chinese companies. For me, having been exposed to Chinese companies before and experiencing the different scale at which they operate it was still a surprise - but much less so that to some of the others.

Open Source Presentation Day

On the Saturday (selected so that it would be easier for engineers to attend), we had a half-day presentation session. We will post the presentations in a week or two, once we are sure we have all the final presentations from both the team members and the two local speakers.

Press Coverage

There have already been at least three articles written based on the interviews with Paul Yang from BaishanCloud, Tim Hudson, and Steve Marquess from the OpenSSL team. We expect there will be many more.

• FreeBuf
• Leiphone
• iTuring Press

Fond Memories

We experienced the beautiful lakes, trees, forests, temples, art and even some music. We climbed up ancient steps, walked through buildings made long ago, and listened to stories from another century. None of this was why we came to China - but we are all grateful for the experiences that our hosts provided us and the thinking and planning that clearly went into the visit.

We all took photos - ranging from the professional camera equipment (Richard) to the cheapest phone money can buy with a tiny little screen (Steve) to the range of different smartphones the rest of us (Matt, Rich and myself) use on a daily basis. When Richard’s camera ran out of battery he switched to his phone and kept taking photos. We have so many amazing photos that will help us all remember this experience for years to come.

New Friends

I have made new friends on this trip - friends that I plan to stay in touch with now that I know what the “right” way to communicate that works when talking with China based engineers. The tools and language may be different - but there is enough in common with the goals and aspirations that we can all work together.

Over the past few years we’ve come to the realisation that there is a surprising (to us) amount of interest in OpenSSL in China. That shouldn’t have been a surprise as China is a huge technologically advanced country, but now we know better thanks to correspondence with many new Chinese contacts and the receipt of significant support from multiple Chinese donors (most notably from Smartisan.

We have accepted an invitation from BaishanCloud to visit China in person and meet with interested OpenSSL users and stakeholders in September. We’d like to thank BaishanCloud for hosting us and Paul Yang and his colleagues there for the substantial amount of work that went into arranging this trip.

Five of us (Matt Caswell, Tim Hudson, Richard Levitte, Steve Marquess and Rich Salz) will be in China from 18 September through 24 September, visiting Shanghai, Shenzhen, and Beijing. With this trip we hope to learn more about this significant portion of the open source and OpenSSL user communities, and hope to make OpenSSL more visible and accessible to that audience. Note that while not quite constituting a OpenSSL team meeting, this will be only the third time any significant number of the OpenSSL team have met in person.

We will presenting on various aspects of OpenSSL on 23 September 2017 in Beijing. An introduction to the event and a registration link are available in Chinese.

We will also be visiting Shanghai and Shenzhen earlier that week to meet with members of the open source community and OpenSSL users and stakeholders. If you can’t make it to the presentation above it may be possible to arrange to meet up with you in one of the above locations. Please drop us a line if you are interested in meeting with us.

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.

As announced here recently Oracle remains a sponsor but will hopefully not be the only sponsor for long. We will continue to partner with Acumen and we have been working extensively with Ashit Vora and Tony Busciglio there to sort out some new ideas.

No code has been written yet as we’re still developing a technical strategy and design. We’ve considered some new approaches to structuring the module, perhaps even as a related set of “bound” modules instead of one monolithic module as for past validations. Carefully sorting through the implications of design decisions for FIPS 140 requirements is a tedious but necessary process, and I think we’ll make faster progress overall by not rushing to the coding stage.

As always we’re interested in hearing from stakeholders (and especially prospective sponsors!), please contact me at marquess@openssl.com or Jim Wright at Oracle at jim.wright@oracle.com.

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.

The bad news is that the Oracle funding will only partially cover the FIPS module work (for perhaps a couple of months), at which point we may have to set that work aside. Hand-to-mouth funding is not a new experience for us though so we’ll worry about that later.

The FIPS module is heavily shaped and constrained (one could even say distorted and contorted) by FIPS 140 requirements. Those requirements (or technically speaking the interpretation of those requirements) has changed considerably since our last open source based validation in 2013, so we’re starting with a careful study of the many requirements changes that have accumulated since then. That study will generate a lot of questions for the accredited test lab, as the practical application of the formal requirements to working code is rarely obvious to anyone.

One goal for this new FIPS module is to make a clean break from the legacy code base of the previous module, which started as a stripped and bastardized version of an old copy of OpenSSL. We’ll be making the new module as simple as possible without extraneous vestigial code. It will live in a new separate git repository, though don’t expect to see a lot of code right away as we work through the requirements questions.

As before the FIPS module will be primarily intended for use with OpenSSL proper, though we hope to minimize (or even eliminate) FIPS specific code in OpenSSL by enhancing the current ENGINE interface. The new FIPS module will have an internal API (with non-opaque structures) that in turn will be wrapped in a higher level ENGINE interface package external to the “cryptographic module boundary”. All three components (formal validated module, module interface wrapper, and OpenSSL proper) will as before be usable as a seamless “FIPS capable” OpenSSL library.

The test suite software will interface with the module directly, and that code will be separate from the module itself. We’ll be sorting out the outlines of these separate components as soon as we’ve confirmed we understand the new requirements.

I’ll blog more as we finalize additional details.

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: