On Wed, May 16, 2018 at 08:46:56AM +0200, Christian Ehrhardt wrote: > On Wed, May 9, 2018 at 8:50 AM, Miroslav Lichvar <mlich...@redhat.com> > wrote: > > As I understand it, this affects quite a few applications and there is > > still some upstream discussion related to the RNG fix. Maybe it will > > sort itself out on the kernel side. > > > You seem to track that already, do you have a few pointers to the Mailing > list archives that cover the ongoing discussion that you could share?
I don't have any pointers. I just saw it mentioned in one of the bugs that were filed for Fedora when the kernel was updated. https://bugzilla.redhat.com/show_bug.cgi?id=1572944 > I Must admit I'm almost tempted to prefer implementing a fallback mechanism > in general (who knows what else than the mentioned kernel changes will > happen and make chrony hit that again). > Is there any argument against implementing the fallback mechanism no matter > what comes out on the kernel side of this discussion? One is that chronyd's start would not be deterministic. If /dev/urandom it's not available (e.g. in a chroot), or the access is blocked by SELinux, AppArmor, etc, chronyd would sometimes fail to start. The other is that falling back to a more predictable PRNG will make it a bit easier to spoof a server reply (i.e. guess the transmit timestamp and the UDP port number). However, we still use /dev/urandom when getrandom() is not available, so the worst supported case will not change. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.