Hi,I'm sure you have heard about OpenBSD's LibreSSL fork of OpenSSL. There has been a lot of code reorganisation and removal. One function which was removed `RAND_egd()` breaks the CPython build. CPython no longer builds on OpenBSD.I have submitted a patch against PyPy already. The application library part of the change can probably be re-used since PyPy borrows CPython's application-level standard library (including the `ssl` and `socket` module). However, for the interpreter level change, the build system will probably have to be hacked. We need to check for the existence of `RAND_egd()` at configure time and only build in support if the function is found.The PyPy patch (and some discussion) is here:https://bitbucket.org/pypy/pypy/pull-request/233/fix-translation-for-libressl-and-fix-ssl/diff#comment-1744605I may have a go at doing this myself (for Python-2.7 at least) if no-one steps up in the meantime; for now just making the CPython devs aware.Thanks

This should wait until the LibreSSL API stabilizes.Regardless, I think we should consider deprecating RAND_egd(). The Entropy Gathering Daemon doesn't seem to have seen a release for more than 10 years... (http://sourceforge.net/projects/egd/files/)

> The PyPy patch (and some discussion) is here:Your patch checks at runtime if libssl comes with RAND_egd:   HAVE_OPENSSL_RAND_EGD = rffi_platform.Has('RAND_egd')In CPython, the _ssl module is compiled in C. How can we check if libssl provides RAND_egd() or not at compile time?Is there a way to check if libssl is OpenSSL or LibreSSL?

Related discussion:http://marc.info/?l=openbsd-tech&m=140512043210089&w=2The answer for Python is:"your package maintainers and ask them to configure these software without egd support."

> In CPython, the _ssl module is compiled in C. How can we check if libssl provides RAND_egd() or not at compile time?How about... checking whether the function is provided? Unless I'm missing some major point, AC_CHECK_FUNC should be good enough.> Is there a way to check if libssl is OpenSSL or LibreSSL?Why would you want to do that? Do you want to make silly assumptions on API depending on provider name, and then add extra conditionals for versions?

> Unless I'm missing some major point, AC_CHECK_FUNC should be good enough.Building extension modules such as ssl doesn't involve autoconf.> Do you want to make silly assumptions on API depending on provider name, and then add extra conditionals for versions?Arguably it would be better if LibreSSL exposed the same API as OpenSSL. We're not responsible for the discrepancy here.

EGD was only necessary for some commercial UNIX systems, versions that needed it all reached end of life. It no longer makes sense to have any code referring to it.        EGD needed until        OS release dateIRIX6.5.19feb 2003Solaris 2.6                     jul 1997AIX     5.2                     oct 2002Tru64   5.1B                    sep 2002HP-UX   11i v2                  sep 2003Please check OpenBSD's patches to remove EGD support from Python for many versions.http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Lib_ssl_pyhttp://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/python/3.4/patches/patch-Lib_ssl_pyhttp://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/python/3.4/patches/patch-Lib_ssl_pyAlternatively see Gentoo's LibreSSL changeshttps://github.com/Sp1l/libressl/tree/master/dev-lang/python

We don't drop feature in minor releases, we are working hard to maintain the backward compatibility.We may only disable RAND_egd if Python is compiled/linked to LibreSSL. So the check should probably be dynamic.

We're still willing to fix this if someone tells us how to test for LibreSSL in C code.

Hi, I think this can be found in LibreSSL's opensslv.h An ifdef LIBRESSL_VERSION_NUMBER should workSeehttps://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src/crypto/opensslv.h_ssl.c includes crypto.h which in turn includes opensslv.h so checking for LIBRESSL_VERSION_NUMBER should provide the correct check.Attached patch does this in C whereas it should be checked for in configure and disabled with a HAS_RAND_egdHave not figured out how to do this conditionally inLib/ssl.py yet

When configure is called with correct LDFLAGS and CPPFLAGS for LibreSSL these patches to configure,Modules/_ssl.c andLib/_ssl.py will detect not having RAND_egd support in OpenSSL and make the build succeed.

patch-configure.ac:-AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features])Why do you remove this define?

I thikn RAND_egd() should probably raise NotImplementedError if the function isn't exposed by the ssl library.

Victor: That is a change that has been implemented in the downstream port to fix wxPython, seehttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 this ended up in this patch as my primary objective was to fix it for the FreeBSD port.Antoine: Sorry, I'm not a python dev... I'm willing to do the work if you can provide the guidance... This was merely a "works-for-me(TM)" patch. Since nothing actually uses egd any longer I would not spend to much effort on it. The odds of anyone requiring EGD support _and_ using LibreSSL are negligable. EGD is last centuries technology, there's no sense in mixing that with current tech.

> Victor: That is a change that has been implemented in the downstream port to fix wxPython, seehttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 this ended up in this patch as my primary objective was to fix it for the FreeBSD port.It looks unrelated to LibreSSL, please split your patch in two parts and open a new issue for the wxPython fix.

Removehttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 patch from this patch-set

> I thikn RAND_egd() should probably raise NotImplementedError if the function isn't exposed by the ssl library.I would prefer to follow the model of the os module: don't declare a function if it is not supported by the OS.

> I would prefer to follow the model of the os module: don't declare a function if it is not supported by the OS.I don't have any strong feelings, so let's do it like that. RAND_egd() isn't useful anyway.

New changeset6f23bc5d480e by Victor Stinner in branch 'default':Issue#21356: Make ssl.RAND_egd() optional to support LibreSSL. Thehttps://hg.python.org/cpython/rev/6f23bc5d480e

Ok, here is a first commit to try to support LibreSSL in Python 3.5.Can someone please test to compile Python 3.5 with LibreSSL and run the test suite (at least test_ssl) to check that everything is fine? If you confirm that the change is correct, I will backport it to Python 2.7 and 3.4. Please mention your version of LibreSSL, OS and OS version in your feedback. LibreSSL has different releases: 2.0 to 2.1.1. Which one was embeded in OpenBSD 5.6?http://www.libressl.org/Bernard Spil's patches don't apply on Python 3.5, I guess that they were written for Python 2.7. I also fixed test_ssl.

FAILED (failures=2, errors=2, skipped=5)That is OK, as these 2 tests should fail with LibreSSL since SSLv2 and SSLv3 support has been removed from LibreSSL.ERROR: test_protocol_sslv23 (__main__.ThreadedTests)ERROR: test_protocol_sslv3 (__main__.ThreadedTests)

> That is OK, as these 2 tests should fail with LibreSSL since SSLv2 and SSLv3 support has been removed from LibreSSL.See the issue#22935.I prefer to wait until this issue is fixed in Python 3.5, and that test_ssl pass on your PC, before backporting this change into Python 2.7 & 3.4.

Merged the patch from haypo back into the FreeBSD port for 2.7 athttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192511In the process I discovered during test_ssl that I had to patchLib/socket.py as well to make RAND_egd conditional

New changeseteddcb6671a48 by Victor Stinner in branch '2.7':Issue#21356: Make ssl.RAND_egd() optional to support LibreSSL. Thehttps://hg.python.org/cpython/rev/eddcb6671a48New changeset7f82f50fdad0 by Victor Stinner in branch '3.4':Issue#21356: Make ssl.RAND_egd() optional to support LibreSSL. Thehttps://hg.python.org/cpython/rev/7f82f50fdad0

Ok, Python 2.7, 3.4 and 3.5 can now be *compiled* with LibreSSL.There are still issues with LibreSSL: see the new issue#23177.