> 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. Cory [0]: See https://github.com/curl/curl/issues/275, https://github.com/curl/curl/pull/524, https://github.com/curl/curl/pull/640
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
