Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux

[Patrick Steinhardt <ps@pks.im>]

On Sun, Mar 16, 2025 at 01:41:40PM -0700, Junio C Hamano wrote:
> "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.

Makes me wonder whether we should also change the order in which Meson
auto-detects functions. That is, do we want the following patch that
favors getrandom over arc4random?

Patrick

diff --git a/meson.build b/meson.build
index d6e27b236fa..501b2becabb 100644
--- a/meson.build
+++ b/meson.build
@@ -1481,15 +1481,15 @@ endif
 
 # Backends are ordered to reflect our preference for more secure and faster
 # ones over the ones that are less so.
-if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
+if csprng_backend in ['auto', 'getrandom'] and compiler.has_header_symbol('sys/random.h', 'getrandom', required: csprng_backend == 'getrandom')
+  libgit_c_args += '-DHAVE_GETRANDOM'
+  csprng_backend = 'getrandom'
+elif csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')
   libgit_c_args += '-DHAVE_ARC4RANDOM'
   csprng_backend = 'arc4random'
 elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')
   libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'
   csprng_backend = 'arc4random_bsd'
-elif csprng_backend in ['auto', 'getrandom'] and compiler.has_header_symbol('sys/random.h', 'getrandom', required: csprng_backend == 'getrandom')
-  libgit_c_args += '-DHAVE_GETRANDOM'
-  csprng_backend = 'getrandom'
 elif csprng_backend in ['auto', 'getentropy'] and compiler.has_header_symbol('unistd.h', 'getentropy', required: csprng_backend == 'getentropy')
   libgit_c_args += '-DHAVE_GETENTROPY'
   csprng_backend = 'getentropy'