potential changes to random number generation for libgcrypt
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sat Apr 28 00:13:29 CEST 2018
On Tue 2018-04-17 12:59:19 -0700, Daniel Kahn Gillmor wrote:
> Rather than recommending that distributions make a compile- or
> packaging-time decision about whether to assume that the kernel has
> getrandom() available, the better choice is for gcrypt to make that
> decision at runtime, based on the current kernel.
> I believe that's what my proposal does, while leaving untouched the
> semantics and behavior of gcrypt on other platforms (and on Linux
> kernels that do not support getrandom()).
Can i get some feedback on the proposed patch? Is there missing
analysis, or faulty reasoning in the rationale for it?
If it's acceptable, i'd like to try to get it merged. If it's not
acceptable, i'd like to understand what's wrong with it.
thanks for taking the time to think this through,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the Gcrypt-devel