From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Taylor Blau <me@ttaylorr.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org
Subject: Re: [PATCH 2/2] wrapper: use a CSPRNG to generate random file names
Date: Tue, 16 Nov 2021 14:21:22 -0500 [thread overview]
Message-ID: <YZQEsjidbBUgvhfu@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqtugc9bdz.fsf@gitster.g>
On Tue, Nov 16, 2021 at 10:57:28AM -0800, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> >> 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".
-Peff
next prev parent reply other threads:[~2021-11-16 19:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 3:35 [PATCH 0/2] Generate temporary files using a CSPRNG brian m. carlson
2021-11-16 3:35 ` [PATCH 1/2] wrapper: add a helper to generate numbers from " brian m. carlson
2021-11-16 15:31 ` Jeff King
2021-11-16 16:01 ` rsbecker
2021-11-16 18:22 ` Taylor Blau
2021-11-16 19:58 ` rsbecker
2021-11-16 22:41 ` brian m. carlson
2021-11-16 23:20 ` rsbecker
2021-11-17 0:47 ` Carlo Arenas
2021-11-17 3:05 ` rsbecker
2021-11-17 1:03 ` brian m. carlson
2021-11-17 1:50 ` Carlo Arenas
2021-11-17 3:04 ` Jeff King
2021-11-17 3:12 ` rsbecker
2021-11-17 3:36 ` Carlo Arenas
2021-11-17 20:01 ` Jeff King
2021-11-17 20:19 ` rsbecker
2021-11-17 23:30 ` brian m. carlson
2021-11-17 23:34 ` rsbecker
2021-11-17 3:03 ` rsbecker
2021-11-17 7:39 ` Junio C Hamano
2021-11-17 23:01 ` brian m. carlson
2021-11-18 7:19 ` Junio C Hamano
2021-11-18 22:16 ` brian m. carlson
2021-11-22 9:10 ` Junio C Hamano
2021-11-16 3:35 ` [PATCH 2/2] wrapper: use a CSPRNG to generate random file names brian m. carlson
2021-11-16 15:36 ` Jeff King
2021-11-16 18:28 ` Taylor Blau
2021-11-16 18:57 ` Junio C Hamano
2021-11-16 19:21 ` Jeff King [this message]
2021-11-16 19:33 ` Taylor Blau
2021-11-16 15:44 ` [PATCH 0/2] Generate temporary files using a CSPRNG Jeff King
2021-11-16 22:17 ` brian m. carlson
2021-11-16 22:29 ` rsbecker
2021-11-16 20:35 ` Ævar Arnfjörð Bjarmason
2021-11-16 21:06 ` Jeff King
2021-11-17 8:36 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YZQEsjidbBUgvhfu@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).