From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>,
GIT Mailing-list <git@vger.kernel.org>,
Patrick Steinhardt <ps@pks.im>,
Adam Dinwoodie <git@dinwoodie.org>
Subject: Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux
Date: Sun, 16 Mar 2025 13:41:40 -0700 [thread overview]
Message-ID: <xmqqr02wbtdn.fsf@gitster.g> (raw)
In-Reply-To: <Z9YbJFJjtXNYnTzk@tapette.crustytoothpaste.net> (brian m. carlson's message of "Sun, 16 Mar 2025 00:28:20 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> When arc4random was added to glibc, the Linux kernel CSPRNG maintainer
> argued that it was not a secure approach (I disagree), and convinced the
> glibc maintainers to just make it a wrapper around the Linux kernel
> CSPRNG, which it now is. So there's no actual benefit to calling
> arc4random versus getrandom, and since it's newer and less commonly
> available than getrandom, as well as slightly slower (because of an
> extra function call), getrandom should be preferred.
This
https://www.phoronix.com/news/GNU-Glibc-arc4random-Functions
was the first hit of my search in the area, but I think you are
referring to
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=eaad4f9
that happened 5 days after the thing got in and the code there tells
me that your summary of the situation is quite accurate.
So I agree that dropping this patch makes sense, but do we want to
do a bit more to improve the situation?
Here is an attempt to improve what we have in Makefile (and possibly
the Linux section in config.mak.uname, but that is improving what we
do not have) to tell folks that arc4random in glibc is only for
compatibility and they should pick getrandom() until the situation
changes.
--- >8 ---
Subject: config/Makefile: a note on CSPRNG_METHOD choice for Linux
arc4random() was added to glibc in July 2022, but quickly replaced
by a stub implementation that wraps around getrandom(). Hence there
is no actual benefit to calling arc4random() over getrandom() on
glibc based systems, at least for now.
To avoid enticing Linux users to choose arc4random(), leave a note
that their arc4random() in glibc is not the same as what their
friends use on other platforms, and guide them to use getrandom()
instead in the meantime.
Helped-by: "brian m. carlson" <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 5 +++--
config.mak.uname | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git c/Makefile w/Makefile
index 7315507381..7214936295 100644
--- c/Makefile
+++ w/Makefile
@@ -155,8 +155,9 @@ include shared.mak
# Define NO_TRUSTABLE_FILEMODE if your filesystem may claim to support
# the executable mode bit, but doesn't really do so.
#
-# Define CSPRNG_METHOD to "arc4random" if your system has arc4random and
-# arc4random_buf, "libbsd" if your system has those functions from libbsd,
+# Define CSPRNG_METHOD to "arc4random" if your system has true arc4random and
+# arc4random_buf (not wrappers around "getrandom" shipped with glibc),
+# "libbsd" if your system has those functions from libbsd,
# "getrandom" if your system has getrandom, "getentropy" if your system has
# getentropy, "rtlgenrandom" for RtlGenRandom (Windows only), or "openssl" if
# you'd want to use the OpenSSL CSPRNG. You may set multiple options with
diff --git c/config.mak.uname w/config.mak.uname
index b12d4e168a..6bf511f24b 100644
--- c/config.mak.uname
+++ w/config.mak.uname
@@ -58,6 +58,8 @@ ifeq ($(uname_S),Linux)
NEEDS_LIBRT = YesPlease
HAVE_SYNC_FILE_RANGE = YesPlease
HAVE_GETDELIM = YesPlease
+ # note: don't choose arc4random on glibc systems
+ CSPRNG_METHOD =
FREAD_READS_DIRECTORIES = UnfortunatelyYes
BASIC_CFLAGS += -DHAVE_SYSINFO
PROCFS_EXECUTABLE_PATH = /proc/self/exe
next prev parent reply other threads:[~2025-03-16 20:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-15 2:49 [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux Ramsay Jones
2025-03-16 0:28 ` brian m. carlson
2025-03-16 20:41 ` Junio C Hamano [this message]
2025-03-16 21:57 ` Ramsay Jones
2025-03-19 13:30 ` Patrick Steinhardt
2025-03-20 1:28 ` Ramsay Jones
2025-03-20 5:20 ` Patrick Steinhardt
2025-03-20 16:41 ` Ramsay Jones
2025-03-16 21:51 ` Ramsay Jones
2025-03-16 23:52 ` 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=xmqqr02wbtdn.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@dinwoodie.org \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=ramsay@ramsayjones.plus.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).