[PATCH] OpenSSL: BoringSSL has SSL_get_client_random, etc.

[Jouni Malinen]

On Thu, May 05, 2016 at 06:41:19PM -0400, David Benjamin wrote:
> So, previously, our approach was not to try to support old versions of
> BoringSSL much. It's annoying having our own code (much less yours!)
> saddled with #ifdefs for our past mistakes. (You all have enough of a
> mess on your hands with multiple versions of OpenSSL. I don't want to
> make things worse!) Instead, we only use it in environments with
> controlled versions that move forwards, so we can coordinate caller
> and callee updates, sometimes even atomically. If atomic changes
> aren't possible, we'd add very temporary scaffolding #defines and
> #ifdefs locally, get to the end state (caller and callee both assumed
> new enough) as fast as possible, and dismantle it.

In theory, that would be nice in case all components using BoringSSL are
only used in the same controlled environment..

> Though talking with Dmitry some more, it sounds like it's actually
> desirable to be able to build newer wpa_supplicant against a release
> or two behind of AOSP? Is that right? This isn't how we had previous
> done things on the BoringSSL end, but we can certainly accommodate it.

Yes, my goal is to be able to take a master branch snapshot from
hostap.git and be able to build wpa_supplicant from that with at least
the latest releases AOSP version or ideally two if the previous one is
still being used in significant new development. Quite a bit of Wi-Fi
related work happens with and on Android versions that are a bit older
than what is in the latest development trees (especially if those trees
are not always publicly available).

If this can be maintained with couple of well placed #ifdefs, then so be
it. I'm willing to take that temporary extra complexity to get the
benefits of having a new version that can be built on top of Android
versions that are used as the baseline for ongoing development and
product releases.

> I can start a BORINGSSL_API_VERSION counter and roll that into AOSP
> now. This will be a random meaningless number except we promise it
> will only increase and we'll probably increment it at points vaguely
> corresponding with additions or changes in the API, wherever it ends
> up convenient to do so. :-) Then this patch will be updated to be
> defined(BORINGSSL_API_VERSION). In future we'd do
> BORINGSSL_API_VERSION > whatever. And then you all can figure out how
> far back it should go. (For my part, I want to minimize your burden,
> so I would encourage you need to retain support for versions older
> than you need, but it sounds like your master branch cares about more
> Android releases than I thought.)
> 
> Does that sound reasonable?

Yes, this would work fine for me and the updated patch you sent looked
good as well.

And as a side note, most of my automated testing is on non-Android
platforms with Linux, so it is a significant benefit to be able to build
the latest wpa_supplicant with number of snapshots of BoringSSL on
x86_64 Linux. This allows both the current master branch of BoringSSL
(i.e., what to expect to see in the products in the future) and various
releases version (e.g., based on Android release tags) being used to run
through the mac80211_hwsim test runs for regression testing and to come
up with new test cases to verify issues that may show up in this area.

-- 
Jouni Malinen                                            PGP id EFC895FA