On 2017-08-18 19:42, Kurt Roeckx wrote: > On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote: >> On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote: >>> On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: >>>> On Thu, 2017-08-17 at 12:22 +0000, Salz, Rich via openssl-dev >>>> wrote: >>>>> I understand the concern. The issue I am wrestling with is >>>>> strict >>>>> compatibility with the existing code. Does anyone really *want* >>>>> the >>>>> RNG’s to not reseed on fork? It’s hard to imagine, but maybe >>>>> somewhere someone is. And then it’s not about just reseeding, >>>>> but >>>>> what about when (if) we add other things, like whether or not the >>>>> secure arena gets zero’d in a child? >>>>> >>>>> So let me phrase it this way: does anyone object to changing the >>>>> default so NO_ATFORK must be used to avoid the reseeding and >>>>> other >>>>> things we might add later? >>>> >>>> I can hardly see anyone would be broken if the default is to reseed >>>> RNG on fork. However that might not be true for other atfork >>>> functionalities so perhaps there is a need to make each of these >>>> future >>>> atfork functions configurable and either on or off by default >>>> individually and not as a whole. >>> >>> There might be cases where after fork you're not able to get to >>> /dev/urandom anymore. >> >> I do not think so. Which particular cases do you have on mind? Yes, >> after fork+exec you could for example switch SELinux domain and won't >> be able to access something but immediately after fork it should not be >> so. Also perhaps the reseeding after fork can be made less strict in >> regards to failures reading /dev/urandom or so. > > It seems to me this all depends on the order of things you do to > create a daemon. You could make sure the RNG is inited, chroot, > and then fork for instance. And I suspect there are actually > programs that do it in that order.
The problem with /dev/urandom will go away sooner or later. All major platforms either have a CPRNG syscall for years or introduced one recently. BSD has getentropy(2) for a while, Windows has CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15. Christian -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev