I'm returning from vacation and jumping into the middle of this. Back in the day when I wrote the code that became k5_get_os_entropy we viewed two cases:
* kadmind. There we're likely to sometimes be generating long-term shared secrets, and it seemed like strong random numbers were important. * krb5kdc, where we were generating session keys used for a few hours. It seems like the change to use the getrandom syscall or other code changes have moved all the code to prefer strong random numbers. That seems problematic at startup for the KDC. Even if we do develop a target indicating that the RNG is seeded, do we really want to block the KDC starup on waiting for this target? I see a few issues here: 1) What's the right behavior for the KDC? 2) What's the right behavior for kadmind? 3) Do we want to provide such a service in krb5-kdc or elsewhere? 4) What do we want to do about stretch? It sounds like we need a fix that's small enough that we can backport it to stretch and not make the SRMs grumpy. --Sam
