Re: [PATCH 2/2] wrapper: use a CSPRNG to generate random file names

On Tue, Nov 16, 2021 at 02:21:22PM -0500, Jeff King wrote:

On Tue, Nov 16, 2021 at 10:57:28AM -0800, Junio C Hamano wrote:

quoted

Taylor Blau [off-list ref] writes:

quoted

quoted

I actually wonder if we should simply die() in such a case. That's not
very friendly from a libification stand-point, but we really can't
progress on much without being able to generate random bytes.

Alternatively, we could fall back to the existing code paths. This is
somewhat connected to my suggestion to Randall earlier in the thread.
But I would rather see that fallback done at compile-time for platforms
that don't give us an easy-to-use CSPRNG, and avoid masking legitimate
errors caused from trying to use a CSPRNG that should exist.

Yeah, I do not think we are doing this because the current code is
completely broken and everybody needs to move to CSPRNG that makes
it absoletely safe---rather this is still just making it safer than
the current code, when system support is available.  So a fallback
to the current code would be a good (and easy) thing to have, I
would think.

One challenge for any fallback is that there are security implications.
In particular:

  - the fallback probably needs to be specific to the mktemp code; we
    don't have any callers yet of csprng_bytes(), but anybody using it
    for, say, actual cryptography would be very unhappy if it quietly
    fell back to insecure bytes.

    (I don't have any plans to use it and we don't do very much actual
    crypto ourselves, but one place that _could_ use it is the
    generation of the push-cert nonce seed).

  - I'm not sure if we should fallback for runtime errors or not. E.g.,
    if we try to open /dev/urandom and it isn't there, is it OK to fall
    back to the older, less-secure tempfile method? That's convenient in
    some sense; Git continues to work inside a chroot for which you
    haven't set up /dev/urandom. But it may also be surprising, and
    erring on the side of doing the less secure thing is probably a bad
    idea.

    So the mktemp code probably needs to be aware of the difference
    between "we have no CSPRNG source" and "we were compiled with
    support for a source, but it didn't work".

My opinion is that we should probably not fallback for runtime errors
where we do have a CSPRNG and any errors trying to use it are
legitimate.

I would probably have csprng_bytes() itself only be compiled where we
know we have a CSPRNG. And then I think our implementation of
git_mkstemps_mode() would depend on whether csprng_bytes() was compiled
or not. If it was, then any errors returned by it are propagated to the
caller (or we call die()). If not, then we use the existing, insecure
implementation.

And I think that basically addresses both of your points, namely that
the fallback is specific to the mktemp code, and provides one opinion on
the matter of runtime errors.

Thanks,
Taylor