On Sat, Apr 07, 2018 at 04:48:51PM +0000, Salz, Rich wrote: > > Like I said in the post I just made, I see zero problems with having > that requirement on systems that can support it. I don't see why we > must lower the bar for *everyone* just because we currently need to do > so for VMS.... > > Because > - It is not clear we need to do so
That we need to do what? > - We are not required to do FIPS level DRBG/CSPRNG this release It's not because we don't have a requirement that it can be validated, that we should only implement it half. There are reasons for those requirements, and they are valid even if you don't validate it. There are things we will not be able to do by default, because the OS does not provide what is needed. But I think there is at least enough code in there that you can write something so that the DRBG can be validated. > - It is probably not appropriate in an API/ABI compatible release > - It is not appropriate for a "silent change" I'm not sure what you're talking about with the last 2 items. What changes are you talking about? What I think might come more as something that breaks things is that we now periodically reseed. It's not good enough anymore to have /dev/urandom available at the start and before you chroot, it now also needs to be available after you chroot. Our use of getrandom() when available avoids this a little. But glibc in Debian stable is only at glibc 2.24 while 2.25 is needed. I think we should consider having support for the syscall ourself. We should probably also add support for such functions on *BSD. Kurt _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project