On 15 Mar 2016, at 01:08, Jim Baker
wrote: I have no vested interest in this, other than the continuing work we have done to make Jython compatible with OpenSSL's model, warts and all.
But the fact that BoringSSL cleans up the OpenSSL API (https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md), at the cost of possible backwards breaking API changes looks reasonable. I suppose there is some risk - perhaps the maintainers will decide that returning 1 should mean OK, but that's not going to happen, is it. The real issue here is that no direct exposure of BoringSSL to other packages. I don't think that happens with CPython. (Ironically it happens with Jython, due to how signed jars poorly interact with shading/Java namespace remapping.)
Maintaining security means dealing with the inevitable churn. Did I mention Jython's support of Python-compatible SSL? I think I did :p
It is *possible* to support BoringSSL: curl does. However, the BoringSSL developers *really* only target Chromium when they consider the possibility of breakage, so it costs curl quite a bit of development time[0]. curl accepts that cost because it supports every TLS stack under the sun: given that CPython currently supports exactly one, widening it to two is a very big risk indeed. Cory [0]: See https://github.com/curl/curl/issues/275, https://github.com/curl/curl/pull/524, https://github.com/curl/curl/pull/640