-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
PEP 524: Add os.getrandom() #71965
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Attached patch adds os.getrandom(): thin wrapper on the Linux getrandom() syscall. os.getrandom() can return less bytes than requested. The patch is incomplete: it doesn't include documentation. I chose to not implement a loop to not loose entropy if a following call fails (ex: fail with EINTR). Rationale: We should also add Solaris support later. See also bpo-27776: "PEP-524: Make os.urandom() blocking on Linux". |
Given docs (with the Linux-only platform support disclaimer), +1 for this as an initial implementation. Providing it on Solaris as well can be a separate patch, but it's less important there (since /dev/urandom and os.urandom() are already blocking APIs) |
New changeset 27267d2fb091 by Victor Stinner in branch 'default': |
HAVE_GETRANDOM_SYSCALL seems to be a compile-time library check, not a runtime check. I compiled and run on Linux 3.15.5, and os.getrandom() exists but raises ENOSYS: ====================================================================== Traceback (most recent call last):
File "/media/disk/home/proj/python/cpython/Lib/test/test_os.py", line 1280, in test_getrandom0
empty = os.getrandom(0)
OSError: [Errno 38] Function not implemented |
Huh, I thought I'd already filed an issue for that, but it looks like it was only a security-sig thread: https://mail.python.org/pipermail/security-sig/2016-June/000060.html I've now remedied that omission and filed http://bugs.python.org/issue27990 to cover it explicitly. Since that was a pre-existing problem that also happens to affect this API, rather than something new introduced by Victor's patch, closing this again. |
New changeset 7a243a40b421 by Victor Stinner in branch 'default': |
Oh, I'm surprised the configure sees getrandom() as available. But well ok, the error can occur if you compile Python on a more recent kernel than the running kernel. I fixed the unit test: skip getrandom() tests if getrandom() fails with ENOSYS. Do you think that it's worth to document this case? |
Ah, I'd missed that Martin was talking about the other way around from bpo-27990. Yes, I think it's worth documenting that os.getrandom() may raise OSError if the running kernel doesn't provide the syscall - that's going to be pretty easy to trigger by running a container with Python 3.6 on a container host running an older Linux kernel. |
I run Arch Linux, but only update packages when I have to. As a result, I am running Linux 3.15 installed and running, but the linux-api-headers has more recently been updated to 4.7 (i.e. matching Linux 4.7). |
3.6 is in beta phase. Are you interested to add the feature to 3.7? |
I understand it’s already implemented, and Victor just reopened it for more documentation. |
Right, the only missing piece now is documentation of the ENOSYS case, which end users may encounter if a Python 3.6 binary that supports os.getrandom() is run against an older kernel. That's pretty easy to trigger via containers, as getrandom() was added in Linux 3.17 and hasn't generally been backported to LTS distribution kernels. Debian 8: based on 3.16 So of those potential LTS container hosts, a recent Ubuntu or Fedora container running Python 3.6 will currently get ENOSYS for everything except a fresh Ubuntu 14.04 install that uses the Ubuntu 16.04 kernel. |
Oh sorry, I looked in the wrong location and missed it.
|
New changeset d31b4de433b7 by Victor Stinner in branch '3.6': |
I pushed the fix for the issue bpo-27955, os.urandom() now handles getrandom() failing with EPERM. @christian: Thanks for your review, I pushed a change fixing the two issues that you reported (memory leak and inefficient temporarily buffer). I attached getrandom_errno.patch: a change proposing to document ENOSYS and EPERM. What do you think? |
I think the documentation is too specific. We typically don't document all possible error numbers. Something along the lines "fails with OSError when getrandom is not supported" is sufficient. |
Because of the lack of interest for getrandom_errno.patch, and Christian saying that it's not good to document specific errors, I now close the bug. Thank you all for your help on this nice security enhancement in Python 3.6! |
Misc/NEWS
so that it is managed by towncrier #552Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: