From: "René Scharfe" <l.s.r@web.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
rsbecker@nexbridge.com, "Taylor Blau" <me@ttaylorr.com>,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v3 1/2] wrapper: add a helper to generate numbers from a CSPRNG
Date: Tue, 18 Jan 2022 14:31:01 +0100 [thread overview]
Message-ID: <fdab40cf-572c-d5a1-3dc0-8afe736c38af@web.de> (raw)
In-Reply-To: <220118.86v8yhpdmr.gmgdl@evledraar.gmail.com>
Am 18.01.22 um 10:45 schrieb Ævar Arnfjörð Bjarmason:
>
> On Mon, Jan 17 2022, brian m. carlson wrote:
>
>> +int csprng_bytes(void *buf, size_t len)
>> +{
>> +#if defined(HAVE_ARC4RANDOM) || defined(HAVE_ARC4RANDOM_LIBBSD)
>> + /* This function never returns an error. */
>> + arc4random_buf(buf, len);
>> + return 0;
>> +#elif defined(HAVE_GETRANDOM)
>> + ssize_t res;
>> + char *p = buf;
>> + while (len) {
>> + res = getrandom(p, len, 0);
>> + if (res < 0)
>> + return -1;
>> + len -= res;
>> + p += res;
>> + }
>> + return 0;
>> +#elif defined(HAVE_GETENTROPY)
>> + int res;
>> + char *p = buf;
>> + while (len) {
>> + /* getentropy has a maximum size of 256 bytes. */
>> + size_t chunk = len < 256 ? len : 256;
>> + res = getentropy(p, chunk);
>> + if (res < 0)
>> + return -1;
>> + len -= chunk;
>> + p += chunk;
>> + }
>> + return 0;
>> +#elif defined(HAVE_RTLGENRANDOM)
>> + if (!RtlGenRandom(buf, len))
>> + return -1;
>> + return 0;
>> +#elif defined(HAVE_OPENSSL_CSPRNG)
>> + int res = RAND_bytes(buf, len);
>> + if (res == 1)
>> + return 0;
>> + if (res == -1)
>> + errno = ENOTSUP;
>> + else
>> + errno = EIO;
>> + return -1;
>
> Why fake up errno here instead of just returning -1? In 2/2 you call
> error_errno(). This seems buggy for a function that doesn't clear errno
> and doesn't guarantee that it's set on failure....
Clearing errno is unnecessary as long as it's always set on error and
the return code indicates whether to look at it. Translating the return
codes of RAND_bytes to suitable errno values makes sense if the goal is
to consistently report errors that way on all platforms.
arc4random_buf never fails, getrandom and getentropy do set errno, so no
translation is needed for them. RAND_bytes doesn't set errno according
to [1], and the translation above looks sensible.
RtlGenRandom also doesn't set errno according to [2], but a translation
is missing above. Should it set errno to EIO in the error case?
[1] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html
[2] https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom
>
>> +#else
>> + ssize_t res;
>> + char *p = buf;
>> + int fd, err;
>> + fd = open("/dev/urandom", O_RDONLY);
>> + if (fd < 0)
>> + return -1;
>> + while (len) {
>> + res = xread(fd, p, len);
>> + if (res < 0) {
>> + err = errno;
>> + close(fd);
>> + errno = err;
>> + return -1;
>> + }
>> + len -= res;
>> + p += res;
>> + }
>> + close(fd);
>> + return 0;
>> +#endif
>> +}
>
> ...seems better to turn it into a "int *failure_errno" parameter
> instead, or just have the function itself call error_errno() in these
> cases.
>
> You can't just check "if (errno)" either due to the return value of
> close() not being checked here...
If the last close(2) call fails for some reason then callers of
csprng_bytes() won't notice due to the return code being zero, nor do
they care -- they got their random data and they cannot do anything
about the file descriptor that now hangs in limbo. So this code looks
OK to me.
René
next prev parent reply other threads:[~2022-01-18 13:31 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fdab40cf-572c-d5a1-3dc0-8afe736c38af@web.de \
--to=l.s.r@web.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=rsbecker@nexbridge.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.
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 NNTP newsgroup(s).