[PATCH 5/5] crypt_make_salt(): try to use actual random bytes for salt generation

[Rasmus Villemoes]

On 15/04/2024 21.05, Steffen Nurpmeso wrote:
> Rasmus Villemoes wrote in
>  <20240415125628.780178-6-rasmus.villemoes at prevas.dk>:
>  |Instead of limiting the possible generated salts to 2^32 different
>  |ones, try to get some actual random bits and mix those in. Keep the
>  |old pseudo-random generation in place, so that even if
>  |open_read_close() fails or only returns a partial result, we're not
>  |doing any worse than previously.
>  |
>  |In fact, even with /dev/urandom being unavailable, this might still
>  |improve things a bit since whatever sort-of random content might be in
>  |the p buffer on entry is then mixed in.
> 
> By that time i thought (completely unrelated with your work) that
> the code from miscutils/seedrng.c which has a more broad view of
> where to get random data from should possibly be generalized.
> There are more than just one match for /dev/urandom, and they all
> want some random bits.

Yeah, I know, I did go grepping for 'random' to see if bb already had
some "gimme some random bytes" helper, and I've also sort-of followed
the seedrng saga. But since there was no such helper, and just
best-effort here is good enough for a significant improvement in the
normal case, I just went with the oneliner open_read_close(), which is
also used in generate_uuid() without checking the return value. If some
common infrastructure for randomness should materialize, this can
trivially be switched over. But I really didn't want to tie this series
to creation of and bikeshedding over such infrastructure.

Rasmus