git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, rsbecker@nexbridge.com,
	"Taylor Blau" <me@ttaylorr.com>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Subject: Re: [PATCH v2 1/2] wrapper: add a helper to generate numbers from a CSPRNG
Date: Tue, 4 Jan 2022 22:56:33 +0000	[thread overview]
Message-ID: <YdTQodIhZ9273nJE@camp.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqsfu3b4gw.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 4912 bytes --]

On 2022-01-04 at 21:01:19, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > +ifeq ($(strip $(CSPRNG_METHOD)),arc4random)
> > +	BASIC_CFLAGS += -DHAVE_ARC4RANDOM
> > +endif
> > +
> > +ifeq ($(strip $(CSPRNG_METHOD)),arc4random-libbsd)
> > +	BASIC_CFLAGS += -DHAVE_ARC4RANDOM_LIBBSD
> > +	EXTLIBS += -lbsd
> > +endif
> > +
> > +ifeq ($(strip $(CSPRNG_METHOD)),getrandom)
> > +	BASIC_CFLAGS += -DHAVE_GETRANDOM
> > +endif
> > +
> > +ifeq ($(strip $(CSPRNG_METHOD)),getentropy)
> > +	BASIC_CFLAGS += -DHAVE_GETENTROPY
> > +endif
> > +
> > +ifeq ($(strip $(CSPRNG_METHOD)),rtlgenrandom)
> > +	BASIC_CFLAGS += -DHAVE_RTLGENRANDOM
> > +endif
> > +
> > +ifeq ($(strip $(CSPRNG_METHOD)),openssl)
> > +	BASIC_CFLAGS += -DHAVE_OPENSSL_CSPRNG
> > +endif
> 
> Use of $(strip ($VAR)) looks a bit different from what everybody
> else does with ifeq in this Makefile.  Was there a particular reason
> to use it that I am missing?

As far as I'm aware, ifeq includes whitespace in its comparisons (at
least, I was led to believe that by the documentation for GNU make).
However, in many places, we insert leading spaces before the variable
name.  Some testing shows that GNU make strips those off, although my
earlier testing led me to believe otherwise.

So I'll change this in v3.

> When we see something unrecognized in CSPRNG_METHOD, we do not touch
> BASIC_CFLAGS (or EXTLIBS) here.  I wonder how easy a clue we would
> have to decide that we need to fall back to urandom.  IOW, I would
> have expected a if/else if/... cascade that has "no we do not have
> anything else and need to fall back to urandom" at the end.

I tried to avoid the if/else if cascade for the same reasons that we do
in config.mak.uname, which is that it gets pretty hard to reason about
after you have more than just a few items.

> > diff --git a/t/helper/test-csprng.c b/t/helper/test-csprng.c
> > new file mode 100644
> > index 0000000000..65d14973c5
> > --- /dev/null
> > +++ b/t/helper/test-csprng.c
> > @@ -0,0 +1,29 @@
> > +#include "test-tool.h"
> > +#include "git-compat-util.h"
> > +
> > +
> > +int cmd__csprng(int argc, const char **argv)
> > +{
> > +	unsigned long count;
> > +	unsigned char buf[1024];
> > +
> > +	if (argc > 2) {
> > +		fprintf(stderr, "usage: %s [<size>]\n", argv[0]);
> > +		return 2;
> > +	}
> > +
> > +	count = (argc == 2) ? strtoul(argv[1], NULL, 0) : -1L;
> > +
> > +	while (count) {
> > +		unsigned long chunk = count < sizeof(buf) ? count : sizeof(buf);
> 
> "chunk" should be of type "size_t", no?

Yes, it should.  Will fix in v3.

> > diff --git a/wrapper.c b/wrapper.c
> > index 36e12119d7..1052356703 100644
> > --- a/wrapper.c
> > +++ b/wrapper.c
> > @@ -702,3 +702,69 @@ int open_nofollow(const char *path, int flags)
> >  	return open(path, flags);
> >  #endif
> >  }
> > +
> > +int csprng_bytes(void *buf, size_t len)
> > +{
> > +#if defined(HAVE_ARC4RANDOM) || defined(HAVE_ARC4RANDOM_LIBBSD)
> 
> Shouldn't HAVE_ARC4RANDOM mean "we have arc4random_buf() function
> available; please use that.", i.e. wouldn't this give us cleaner
> result in the change to the Makefile?
> 
>  ifeq ($(strip $(CSPRNG_METHOD)),arc4random)
>  	BASIC_CFLAGS += -DHAVE_ARC4RANDOM
>  endif
>  
>  ifeq ($(strip $(CSPRNG_METHOD)),arc4random-libbsd)
> -	BASIC_CFLAGS += -DHAVE_ARC4RANDOM_LIBBSD
> +	BASIC_CFLAGS += -DHAVE_ARC4RANDOM
>  	EXTLIBS += -lbsd
>  endif
> 
> To put it differently, C source, via BASIC_CFLAGS, would not have to
> care where the function definition comes from.  It is linker's job
> to care and we are already telling it via EXTLIBS, so I am not sure
> the value of having HAVE_ARC4RANDOM_LIBBSD as a separate symbol.

There's an important additional difference here.  On real BSD systems,
the prototypes for this family of functions live in <stdlib.h>.
Obviously, on Linux with libbsd, that's not the case.  So, in
git-compat-util.h, we need to include <bsd/stdlib.h> to get the
prototype, and that's done only if HAVE_ARC4RANDOM_LIBBSD is set, since
on a real BSD system, that header isn't present.

If you'd prefer, I can set both flags here, one which controls the
function use and one which controls the #define, or I can leave it as it
is.

> OK, I earlier worried about the lack of explicit "we are using
> urandom" at the Makefile level, but as long as this will remain the
> only place that needs to care about the fallback, the above is
> perfectly fine.

Yes, I tried very hard to make this the only place the default mattered.

And, for the record, I think /dev/urandom is the sensible default here,
because I know it exists on some of the proprietary Unix systems, like
Solaris, where I believe it originated, and QNX, as well as Linux and
the BSDs.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  parent reply	other threads:[~2022-01-04 22:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04  1:55 [PATCH v2 0/2] Generate temporary files using a CSPRNG brian m. carlson
2022-01-04  1:55 ` [PATCH v2 1/2] wrapper: add a helper to generate numbers from " brian m. carlson
2022-01-04 21:01   ` Junio C Hamano
2022-01-04 21:39     ` Junio C Hamano
2022-01-04 23:12       ` brian m. carlson
2022-01-04 22:56     ` brian m. carlson [this message]
2022-01-04 23:17       ` Junio C Hamano
2022-01-04  1:55 ` [PATCH v2 2/2] wrapper: use a CSPRNG to generate random file names brian m. carlson
2022-01-04 12:44 ` [PATCH v2 0/2] Generate temporary files using a CSPRNG Johannes Schindelin
2022-01-17 21:56 ` [PATCH v3 " brian m. carlson
2022-01-17 21:56   ` [PATCH v3 1/2] wrapper: add a helper to generate numbers from " brian m. carlson
2022-01-18  9:45     ` Ævar Arnfjörð Bjarmason
2022-01-18 13:31       ` René Scharfe
2022-01-17 21:56   ` [PATCH v3 2/2] wrapper: use a CSPRNG to generate random file names brian m. carlson
2022-01-18  9:24     ` Ævar Arnfjörð Bjarmason
2022-01-18 14:42       ` René Scharfe
2022-01-18 14:51         ` Ævar Arnfjörð Bjarmason
2022-01-18 16:44           ` René Scharfe
2022-01-18 17:25         ` Junio C Hamano
2022-01-19 17:49           ` René Scharfe
2022-01-22 10:41           ` René Scharfe
2022-01-24 17:08             ` Junio C Hamano
2022-01-19  3:28       ` brian m. carlson

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=YdTQodIhZ9273nJE@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=rsbecker@nexbridge.com \
    /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).