[th/bad-random-bytes] glib-aux: rework fallback random generator to use sha256
nm_utils_random_bytes()
tries to get good randomness. If it fails, we still
try our own approach, but also signal that the returned numbers are bad.
In practice, none of the callers cares about the return value, because they
wouldn't know what to do in case of bad randomness (abort() is not an
option and retry is not expected to help and sending an email to the
admin isn't gonna help either). So the fallback case really should try
its best.
The fallback case depends on a good random seed and a good pseudorandom number generator.
Getting a good seed is in reality impossible, after kernel let us down. That is part of the problem, but we try our best.
The other part is to use a cryptographic pseudorandom number generator.
GRand
uses a Mersenne Twister, so that is not good enough. In this low
level code we also cannot call gnutls/nss, because usually we don't have
that dependency. Maybe we could copy&paste the chacha20 implementation,
it's simple enough and a compatible license. That might be good, but
instead cock our own by adding some sha256 into the mix. This is
fallback code after all, and we want to try hard, but not that hard to
add chacha20 to NetworkManager.
So, what we do is to use a well seeded GRand instance, and XOR that output with a sha256 digest of the state. It's probably slow, but performance is not the issue in this code path.