If a GNU/Linux system has glibc-2.25 and <linux-3.17, getrandom and getentropy will be declared in system headers, without a syscall implementation in the kernel.

For the build system of python, getentropy gets passed in configure, but fails at runtime, such as:

> Fatal Python error: getentropy() failed

strace gives

> syscall_318(0x7f369b1535d0, 0x18, 0, 0x13e, 0x7f369b1535d0, 0x7f369b1535e8) = -1 (errno 38)

The glibc developers regard testing the usability of a syscall to be a task of python build system.  Besides AC_TEST_FUNCS(... getentropy ...) which only test whether getentropy is defined in the system, runtime checks in configure is needed.

This is a continuation of http://bugs.python.org/issue29157#msg288291.

Does it only affect Python 3.4 and 3.5? Both versions are in security fix-only mode and no longer receive other fixes.

> Does it only affect Python 3.4 and 3.5? Both versions are in security fix-only mode and no longer receive other fixes.

Sorry I haven't noticed that there are two new releases this month Python 3.4.7 and 3.5.4.  The test build results are:

3.4.7 fail
3.4.6 fail
3.5.4 success
3.5.3 fail
3.6.1 success

I will remove the python 3.5 version tag.  Looks like Python 3.5 got this compatibility fix in time before entering security update phase.  But python 3.4 did not, making it incompatible with glibc-2.25 on old linux kernels.

If I understand correctly, Python 3.4 and 3.5 simply don't work on Linux < 3.17 with glibc >= 2.25.

The question is which OS make such change. It seems like the issue is more with binary packages when the builder is older or newer than the OS used by end users.

Since the bug prevents to start Python and cannot be worked again, maybe we need to fix Python 3.4... *but* this branch becomes old, Python 3.5 recently reached the security fixes only.

The pratical issue is that my changes os Python/random.c are large. I refactored the code to fix different issues.

I suggest to fix how binary packages are compiled, upgrade to Python 3.5 or newer, and more generally try to avoid the bad version combo (Linux < 3.17 with glibc >= 2.25) ;-)

I wrote articles on my os.urandom() changes:

* https://haypo.github.io/pep-524-os-urandom-blocking.html
* https://haypo.github.io/contrib-cpython-2017q1.html § os.urandom() and getrandom()

Thanks Victor. Python-3.5 has received your patches in time and 3.5.4 builds well with glibc-2.25 and <linux-3.17.  Python-3.4 and 2.7 do not.

I am backing Gentoo Prefix[1] for normal users to run Gentoo on top of other Linux distributions. The host distribution could be RHEL 5, 6, Ubuntu LTS 14.04, etc, which is still common and with old linux kernels.  Gentoo unstable has been upgraded to glibc-2.25, and Gentoo is using Python-3.4 as default.  Therefore glibc-2.25 + <linux-3.17 + Python-3.4 is a common scenario for us, at least in the near future.

I have made a workaround[2] by exporting ac_cv_func_getentropy=no unconditionally for the moment.

  1. https://wiki.gentoo.org/wiki/Project:Prefix
  2. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6c8e2396d9cf4fe13057741f5bd1b9989eeeb746