> On 15 Mar 2016, at 01:08, Jim Baker <jim.ba...@python.org> 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.


[0]: See https://github.com/curl/curl/issues/275, 
https://github.com/curl/curl/pull/524, https://github.com/curl/curl/pull/640

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Python-Dev mailing list

Reply via email to