700eb415 added the comment:
>From the OpenBSD random(4) man page:
"The arc4random(3) function in userland libraries should be used instead, as it
works without the need to access these devices every time."
Theo just had a good talk on this issue here about why /dev/random needs
r
700eb415 added the comment:
> I'm not sure that arc4random() can be considered as coming from the "OS".
We really have a couple options here. (1)Include a high quality pseudorandom
number function for every platform that doesn't provide the proper call (very
tediou
700eb415 added the comment:
I'm reopening this for now as advised from the Linux getrandom() thread.
I agree we should not be using arc4random() blindly. However, in the long run
it is a necessary change at least on OpenBSD. OpenBSD is not likely to create
another syscall to avoid portab
700eb415 added the comment:
While I agree it may not be wise to use arc4random() globally, OpenBSD is
unlikely to create a duplicate interface since it's already available.
Python is currently unusable in chroots on that platform without reducing the
security of the host partition by rem
700eb415 added the comment:
OpenBSD already provides high quality pseudorandom numbers from arc4random(). I
don't think this would make us "early adopters" since it has been around for
some time on this platform.
It's also worth mentioning that getentropy() is not re
700eb415 added the comment:
It's worth noting that LibreSSL has now enabled the blocked code. If anyone is
interested, I would be willing to help port it.
--
nosy: +700eb415
___
Python tracker
<http://bugs.python.org/is
New submission from 700eb415:
Trying to run the python interpreter in a chroot fails if /dev/urandom is not
present. Removing the "nodev" flag from the filesystem is not ideal in many
situations.
Instead, we should utilize functions such as OpenBSD's arc4random(3) and the
