{"thread":{"id":"63130","subject":"[PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","startedAt":"2025-03-15T02:49:20Z","lastAt":"2025-03-20T16:41:20Z","messageCount":10,"participants":["Ramsay Jones","brian m. carlson","Junio C Hamano","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":12},"messages":[{"id":"514343","messageId":"8c8e16ae-87a2-44bf-a87b-7422eb04fec2@ramsayjones.plus.com","threadId":"63130","inReplyTo":null,"subject":"[PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-15T02:49:18Z","receivedAt":"2025-03-15T02:49:20Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\nCommit 05cd988dce (\"wrapper: add a helper to generate numbers from a\nCSPRNG\", 2022-01-17) added a csprng_bytes() function which used one\nof several interfaces to provide a source of cryptographically secure\npseudorandom numbers. The CSPRNG_METHOD make variable was provided to\ndetermine the choice of available 'backends' for the source of random\nbytes.\n\nCommit 05cd988dce did not set CSPRNG_METHOD in the Linux section of\nthe config.mak.uname file, so it defaults to using '/dev/urandom' as\nthe source of random bytes. The 'backend' values which could be used\non Linux, in order of preference, are 'arc4random', 'getrandom' or\n'getentropy' ('openssl' is an option, but seems to be discouraged).\n\nThe arc4random routines (ar4random_buf() is the one actually used) were\nadded to glibc in version 2.36, while both getrandom() and getentropy()\nwere included in 2.25. So, some of the more up-to-date distributions of\nLinux (eg Debian 12, Ubuntu 24.04) would be able to use the preferred\n'arc4random' setting.\n\nIf the meson build system is used on a newer platform, then they will be\nconfigured to use 'arc4random', whereas the make build will currently\ndefault to using '/dev/urandom'. Add a note to the config.mak.uname file,\nin the Linux section, to prompt make users to override CSPRNG_METHOD in\nthe config.mak file, if appropriate.\n\nSigned-off-by: Ramsay Jones \n---\n config.mak.uname | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/config.mak.uname b/config.mak.uname\nindex 4f6770a5f4..1a897bd022 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -50,6 +50,8 @@ ifeq ($(uname_S),Linux)\n \tHAVE_ALLOCA_H = YesPlease\n \t# override in config.mak if you have glibc >= 2.38\n \tNO_STRLCPY = YesPlease\n+\t# set to arc4random (in config.mak) if you have glibc >= 2.36\n+\tCSPRNG_METHOD =\n \tHAVE_PATHS_H = YesPlease\n \tLIBC_CONTAINS_LIBINTL = YesPlease\n \tHAVE_DEV_TTY = YesPlease\n-- \n2.49.0\n"},{"id":"514367","messageId":"Z9YbJFJjtXNYnTzk@tapette.crustytoothpaste.net","threadId":"63130","inReplyTo":"8c8e16ae-87a2-44bf-a87b-7422eb04fec2@ramsayjones.plus.com","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-03-16T00:28:20Z","receivedAt":"2025-03-16T00:28:28Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-03-15 at 02:49:18, Ramsay Jones wrote:\n> \n> Commit 05cd988dce (\"wrapper: add a helper to generate numbers from a\n> CSPRNG\", 2022-01-17) added a csprng_bytes() function which used one\n> of several interfaces to provide a source of cryptographically secure\n> pseudorandom numbers. The CSPRNG_METHOD make variable was provided to\n> determine the choice of available 'backends' for the source of random\n> bytes.\n> \n> Commit 05cd988dce did not set CSPRNG_METHOD in the Linux section of\n> the config.mak.uname file, so it defaults to using '/dev/urandom' as\n> the source of random bytes. The 'backend' values which could be used\n> on Linux, in order of preference, are 'arc4random', 'getrandom' or\n> 'getentropy' ('openssl' is an option, but seems to be discouraged).\n> \n> The arc4random routines (ar4random_buf() is the one actually used) were\n> added to glibc in version 2.36, while both getrandom() and getentropy()\n> were included in 2.25. So, some of the more up-to-date distributions of\n> Linux (eg Debian 12, Ubuntu 24.04) would be able to use the preferred\n> 'arc4random' setting.\n> \n> If the meson build system is used on a newer platform, then they will be\n> configured to use 'arc4random', whereas the make build will currently\n> default to using '/dev/urandom'. Add a note to the config.mak.uname file,\n> in the Linux section, to prompt make users to override CSPRNG_METHOD in\n> the config.mak file, if appropriate.\n\narc4random operates differently on Linux than it does on the BSDs, and\nthe right choice on Linux is `getrandom`.\n\nThe reason is that on the BSDs, a userspace ChaCha20 which is seeded\nfrom the kernel is used, along with an integer representing whether it's\ninititalize, and this state is stored in a page that is zeroed on fork,\nso that it automatically becomes uninitialized then (and is hence\nreseeded). Because it is in userspace, it avoids the overhead of a\nsyscall, and is thus usually faster. arc4random has also been around\nlonger than getrandom or getentropy on the BSDs and is widely supported\nthere, and so it's generally the right choice (and hence, the default).\n\nWhen arc4random was added to glibc, the Linux kernel CSPRNG maintainer\nargued that it was not a secure approach (I disagree), and convinced the\nglibc maintainers to just make it a wrapper around the Linux kernel\nCSPRNG, which it now is. So there's no actual benefit to calling\narc4random versus getrandom, and since it's newer and less commonly\navailable than getrandom, as well as slightly slower (because of an\nextra function call), getrandom should be preferred.\n\nAll Linux distros within our current support window have glibc 2.25 or\nnewer (RHEL 8 being the oldest one), so we may want to just default to\ngetrandom on Linux.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"514400","messageId":"xmqqr02wbtdn.fsf@gitster.g","threadId":"63130","inReplyTo":"Z9YbJFJjtXNYnTzk@tapette.crustytoothpaste.net","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-16T20:41:40Z","receivedAt":"2025-03-16T20:41:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> When arc4random was added to glibc, the Linux kernel CSPRNG maintainer\n> argued that it was not a secure approach (I disagree), and convinced the\n> glibc maintainers to just make it a wrapper around the Linux kernel\n> CSPRNG, which it now is. So there's no actual benefit to calling\n> arc4random versus getrandom, and since it's newer and less commonly\n> available than getrandom, as well as slightly slower (because of an\n> extra function call), getrandom should be preferred.\n\nThis\n\nhttps://www.phoronix.com/news/GNU-Glibc-arc4random-Functions\n\nwas the first hit of my search in the area, but I think you are\nreferring to\n\nhttps://sourceware.org/git/?p=glibc.git;a=commitdiff;h=eaad4f9\n\nthat happened 5 days after the thing got in and the code there tells\nme that your summary of the situation is quite accurate.\n\nSo I agree that dropping this patch makes sense, but do we want to\ndo a bit more to improve the situation?\n\nHere is an attempt to improve what we have in Makefile (and possibly\nthe Linux section in config.mak.uname, but that is improving what we\ndo not have) to tell folks that arc4random in glibc is only for\ncompatibility and they should pick getrandom() until the situation\nchanges.\n\n--- >8 ---\nSubject: config/Makefile: a note on CSPRNG_METHOD choice for Linux\n\narc4random() was added to glibc in July 2022, but quickly replaced\nby a stub implementation that wraps around getrandom(). Hence there\nis no actual benefit to calling arc4random() over getrandom() on\nglibc based systems, at least for now.\n\nTo avoid enticing Linux users to choose arc4random(), leave a note\nthat their arc4random() in glibc is not the same as what their\nfriends use on other platforms, and guide them to use getrandom()\ninstead in the meantime.\n\nHelped-by: \"brian m. carlson\" \nSigned-off-by: Junio C Hamano \n---\n Makefile | 5 +++--\n config.mak.uname | 2 ++\n 2 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git c/Makefile w/Makefile\nindex 7315507381..7214936295 100644\n--- c/Makefile\n+++ w/Makefile\n@@ -155,8 +155,9 @@ include shared.mak\n # Define NO_TRUSTABLE_FILEMODE if your filesystem may claim to support\n # the executable mode bit, but doesn't really do so.\n #\n-# Define CSPRNG_METHOD to \"arc4random\" if your system has arc4random and\n-# arc4random_buf, \"libbsd\" if your system has those functions from libbsd,\n+# Define CSPRNG_METHOD to \"arc4random\" if your system has true arc4random and\n+# arc4random_buf (not wrappers around \"getrandom\" shipped with glibc),\n+# \"libbsd\" if your system has those functions from libbsd,\n # \"getrandom\" if your system has getrandom, \"getentropy\" if your system has\n # getentropy, \"rtlgenrandom\" for RtlGenRandom (Windows only), or \"openssl\" if\n # you'd want to use the OpenSSL CSPRNG. You may set multiple options with\ndiff --git c/config.mak.uname w/config.mak.uname\nindex b12d4e168a..6bf511f24b 100644\n--- c/config.mak.uname\n+++ w/config.mak.uname\n@@ -58,6 +58,8 @@ ifeq ($(uname_S),Linux)\n \tNEEDS_LIBRT = YesPlease\n \tHAVE_SYNC_FILE_RANGE = YesPlease\n \tHAVE_GETDELIM = YesPlease\n+\t# note: don't choose arc4random on glibc systems\n+\tCSPRNG_METHOD =\n \tFREAD_READS_DIRECTORIES = UnfortunatelyYes\n \tBASIC_CFLAGS += -DHAVE_SYSINFO\n \tPROCFS_EXECUTABLE_PATH = /proc/self/exe\n\n\n\n\n"},{"id":"514401","messageId":"654de230-07cb-4ffe-bfc4-ca0e1d6d3572@ramsayjones.plus.com","threadId":"63130","inReplyTo":"Z9YbJFJjtXNYnTzk@tapette.crustytoothpaste.net","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-16T21:51:45Z","receivedAt":"2025-03-16T21:54:58Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Hi Brian,\n\nOn 16/03/2025 00:28, brian m. carlson wrote:\n> On 2025-03-15 at 02:49:18, Ramsay Jones wrote:\n[snip]\n>> If the meson build system is used on a newer platform, then they will be\n>> configured to use 'arc4random', whereas the make build will currently\n>> default to using '/dev/urandom'. Add a note to the config.mak.uname file,\n>> in the Linux section, to prompt make users to override CSPRNG_METHOD in\n>> the config.mak file, if appropriate.\n> \n> arc4random operates differently on Linux than it does on the BSDs, and\n> the right choice on Linux is `getrandom`.\n> \n> The reason is that on the BSDs, a userspace ChaCha20 which is seeded\n> from the kernel is used, along with an integer representing whether it's\n> inititalize, and this state is stored in a page that is zeroed on fork,\n> so that it automatically becomes uninitialized then (and is hence\n> reseeded). Because it is in userspace, it avoids the overhead of a\n> syscall, and is thus usually faster. arc4random has also been around\n> longer than getrandom or getentropy on the BSDs and is widely supported\n> there, and so it's generally the right choice (and hence, the default).\n> \n> When arc4random was added to glibc, the Linux kernel CSPRNG maintainer\n> argued that it was not a secure approach (I disagree), and convinced the\n> glibc maintainers to just make it a wrapper around the Linux kernel\n> CSPRNG, which it now is. So there's no actual benefit to calling\n> arc4random versus getrandom, and since it's newer and less commonly\n> available than getrandom, as well as slightly slower (because of an\n> extra function call), getrandom should be preferred.\n\nAh, OK, thanks! While researching this I was only concerned about when\nthe functions were available. I didn't give quality/performance a minutes\nthought! ;)\n\n[I am aware, of course, that newer doesn't automatically mean better. It\nseems I forgot about that here - my bad! :( ]\n\nHowever, this afternoon, while I was waiting for the 'meson test' on cygwin\nto finish, I had a quick look at the implementation(s) on glibc and cygwin.\n\nOn cygwin, the arc4random_buf() implementation seems to have been imported\nfrom OpenBSD, and uses a chacha_encrypt_bytes() function call during the\nprocess of creating the random bytes (see newlib/libc/stdlib/arc4random.c\nin the cygwin repo [0]). Also, the getrandom() and getentropy() functions\nare simple wrappers around an RtlGenRandom() call (see winsup/cygwin/libc/\\\ngetentropy.cc in [0]).\n\nThe glibc implementation of arc4random_buf() (see [1]), as you say, is just\na simple wrapper around the Linux 'getrandom syscall'. In addition, we can\nalso confirm that getrandom() (see [2]) and getentropy() (see [3]) are also\nsimple wrappers around the 'getrandom syscall'. However, I don't see the\n'extra function call' you refer to above. (Yes, all the layers of macros does\nobscure things somewhat, but I don't see that extra function call).\n\nWhat am I missing?\n\n[I haven't actually done any tests for quality/performance, so I am quite\nprepared to take your word for it! :) ]\n\nAs you say, arc4random() is less available on Linux, so getrandom() makes\nfor a better default.\n\nAnyway, I guess that means the meson build needs to be modified, since it\ncurrently selects arc4random() on Linux (this is OK on cygwin, see above).\n\n[I was writing an autoconf test for this, which will also need to change!]\n\n\n[0] git://cygwin.com/git/newlib-cygwin.git\n[1] https://codebrowser.dev/glibc/glibc/stdlib/arc4random.c.html\n[2] https://codebrowser.dev/glibc/glibc/sysdeps/unix/sysv/linux/getrandom.c.html\n[3] https://codebrowser.dev/glibc/glibc/sysdeps/unix/sysv/linux/getentropy.c.html\n\n> \n> All Linux distros within our current support window have glibc 2.25 or\n> newer (RHEL 8 being the oldest one), so we may want to just default to\n> getrandom on Linux.\n\nSo, Yes, this patch needs to be dropped.\n\nThanks!\n\nATB,\nRamsay Jones\n\n\n\n"},{"id":"514402","messageId":"9c815bdc-4cc6-4614-a203-105811ebbb59@ramsayjones.plus.com","threadId":"63130","inReplyTo":"xmqqr02wbtdn.fsf@gitster.g","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-16T21:57:43Z","receivedAt":"2025-03-16T21:57:48Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 16/03/2025 20:41, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n>> When arc4random was added to glibc, the Linux kernel CSPRNG maintainer\n>> argued that it was not a secure approach (I disagree), and convinced the\n>> glibc maintainers to just make it a wrapper around the Linux kernel\n>> CSPRNG, which it now is. So there's no actual benefit to calling\n>> arc4random versus getrandom, and since it's newer and less commonly\n>> available than getrandom, as well as slightly slower (because of an\n>> extra function call), getrandom should be preferred.\n> \n> This\n> \n> https://www.phoronix.com/news/GNU-Glibc-arc4random-Functions\n> \n> was the first hit of my search in the area, but I think you are\n> referring to\n> \n> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=eaad4f9\n> \n> that happened 5 days after the thing got in and the code there tells\n> me that your summary of the situation is quite accurate.\n> \n> So I agree that dropping this patch makes sense, but do we want to\n> do a bit more to improve the situation?\n> \n\nYes, this patch should be dropped. (See my reply to Brian; our emails\ncrossed!).\n\nATB,\nRamsay Jones\n\n\n"},{"id":"514404","messageId":"Z9dkJb-HOIQmsEqs@tapette.crustytoothpaste.net","threadId":"63130","inReplyTo":"654de230-07cb-4ffe-bfc4-ca0e1d6d3572@ramsayjones.plus.com","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-03-16T23:52:05Z","receivedAt":"2025-03-16T23:52:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-03-16 at 21:51:45, Ramsay Jones wrote:\n> Ah, OK, thanks! While researching this I was only concerned about when\n> On cygwin, the arc4random_buf() implementation seems to have been imported\n> from OpenBSD, and uses a chacha_encrypt_bytes() function call during the\n> process of creating the random bytes (see newlib/libc/stdlib/arc4random.c\n> in the cygwin repo [0]). Also, the getrandom() and getentropy() functions\n> are simple wrappers around an RtlGenRandom() call (see winsup/cygwin/libc/\\\n> getentropy.cc in [0]).\n\nYeah, that's similar to what I'd expect to see on the BSDs, except that\n`getrandom` or `getentropy` is the actual system call.\n\n> The glibc implementation of arc4random_buf() (see [1]), as you say, is just\n> a simple wrapper around the Linux 'getrandom syscall'. In addition, we can\n> also confirm that getrandom() (see [2]) and getentropy() (see [3]) are also\n> simple wrappers around the 'getrandom syscall'. However, I don't see the\n> 'extra function call' you refer to above. (Yes, all the layers of macros does\n> obscure things somewhat, but I don't see that extra function call).\n\nThere's a call to `__getrandom_nocancel` in a loop, which I believe is the\nfunction wrapping the system call. It's probably inlined, so it's not\nthat big a deal, though.\n\n> As you say, arc4random() is less available on Linux, so getrandom() makes\n> for a better default.\n> \n> Anyway, I guess that means the meson build needs to be modified, since it\n> currently selects arc4random() on Linux (this is OK on cygwin, see above).\n\nIt's not the end of the world if the meson build system automatically\nprefers `arc4random` over `getrandom`. That's a sensible default in the\ngeneral case, and I believe that the use case is generating temporary\nfiles, which will always incur the cost of a context switch and a disk\naccess, so in general the performance difference would be negligible\nanyway. It's not a hot path, since nobody expects us to write millions\nof loose objects, pack files, or other temporary files in the typical\ncase.\n\nI _do_ think that if we're specifying a default in `config.mak` on\nLinux, `getrandom` is the right choice, and I think we can probably just\nhard-code that now and let people override it if they're using a system\nolder than our supported environments that needs `/dev/urandom`.\n\nPOSIX 1003.1-2024 specifies `getentropy`, so my guess is that we'll see\nthat on more and more systems as we go on, and the other choices will be\nless and less necessary, but we're not there yet.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"514637","messageId":"Z9rG3JVA5vSoYynt@pks.im","threadId":"63130","inReplyTo":"xmqqr02wbtdn.fsf@gitster.g","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-03-19T13:30:04Z","receivedAt":"2025-03-19T13:30:13Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sun, Mar 16, 2025 at 01:41:40PM -0700, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > When arc4random was added to glibc, the Linux kernel CSPRNG maintainer\n> > argued that it was not a secure approach (I disagree), and convinced the\n> > glibc maintainers to just make it a wrapper around the Linux kernel\n> > CSPRNG, which it now is. So there's no actual benefit to calling\n> > arc4random versus getrandom, and since it's newer and less commonly\n> > available than getrandom, as well as slightly slower (because of an\n> > extra function call), getrandom should be preferred.\n> \n> This\n> \n> https://www.phoronix.com/news/GNU-Glibc-arc4random-Functions\n> \n> was the first hit of my search in the area, but I think you are\n> referring to\n> \n> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=eaad4f9\n> \n> that happened 5 days after the thing got in and the code there tells\n> me that your summary of the situation is quite accurate.\n> \n> So I agree that dropping this patch makes sense, but do we want to\n> do a bit more to improve the situation?\n> \n> Here is an attempt to improve what we have in Makefile (and possibly\n> the Linux section in config.mak.uname, but that is improving what we\n> do not have) to tell folks that arc4random in glibc is only for\n> compatibility and they should pick getrandom() until the situation\n> changes.\n> \n> --- >8 ---\n> Subject: config/Makefile: a note on CSPRNG_METHOD choice for Linux\n> \n> arc4random() was added to glibc in July 2022, but quickly replaced\n> by a stub implementation that wraps around getrandom(). Hence there\n> is no actual benefit to calling arc4random() over getrandom() on\n> glibc based systems, at least for now.\n> \n> To avoid enticing Linux users to choose arc4random(), leave a note\n> that their arc4random() in glibc is not the same as what their\n> friends use on other platforms, and guide them to use getrandom()\n> instead in the meantime.\n\nMakes me wonder whether we should also change the order in which Meson\nauto-detects functions. That is, do we want the following patch that\nfavors getrandom over arc4random?\n\nPatrick\n\ndiff --git a/meson.build b/meson.build\nindex d6e27b236fa..501b2becabb 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -1481,15 +1481,15 @@ endif\n \n # Backends are ordered to reflect our preference for more secure and faster\n # ones over the ones that are less so.\n-if csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')\n+if csprng_backend in ['auto', 'getrandom'] and compiler.has_header_symbol('sys/random.h', 'getrandom', required: csprng_backend == 'getrandom')\n+ libgit_c_args += '-DHAVE_GETRANDOM'\n+ csprng_backend = 'getrandom'\n+elif csprng_backend in ['auto', 'arc4random'] and compiler.has_header_symbol('stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random')\n libgit_c_args += '-DHAVE_ARC4RANDOM'\n csprng_backend = 'arc4random'\n elif csprng_backend in ['auto', 'arc4random_bsd'] and compiler.has_header_symbol('bsd/stdlib.h', 'arc4random_buf', required: csprng_backend == 'arc4random_bsd')\n libgit_c_args += '-DHAVE_ARC4RANDOM_BSD'\n csprng_backend = 'arc4random_bsd'\n-elif csprng_backend in ['auto', 'getrandom'] and compiler.has_header_symbol('sys/random.h', 'getrandom', required: csprng_backend == 'getrandom')\n- libgit_c_args += '-DHAVE_GETRANDOM'\n- csprng_backend = 'getrandom'\n elif csprng_backend in ['auto', 'getentropy'] and compiler.has_header_symbol('unistd.h', 'getentropy', required: csprng_backend == 'getentropy')\n libgit_c_args += '-DHAVE_GETENTROPY'\n csprng_backend = 'getentropy'\n"},{"id":"514704","messageId":"74b2838e-1d7b-4ee0-a4a7-e3d21f4e6597@ramsayjones.plus.com","threadId":"63130","inReplyTo":"Z9rG3JVA5vSoYynt@pks.im","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-20T01:28:31Z","receivedAt":"2025-03-20T01:31:42Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 19/03/2025 13:30, Patrick Steinhardt wrote:\n> On Sun, Mar 16, 2025 at 01:41:40PM -0700, Junio C Hamano wrote:\n>> \"brian m. carlson\" writes:\n>>\n>>> When arc4random was added to glibc, the Linux kernel CSPRNG maintainer\n>>> argued that it was not a secure approach (I disagree), and convinced the\n>>> glibc maintainers to just make it a wrapper around the Linux kernel\n>>> CSPRNG, which it now is. So there's no actual benefit to calling\n>>> arc4random versus getrandom, and since it's newer and less commonly\n>>> available than getrandom, as well as slightly slower (because of an\n>>> extra function call), getrandom should be preferred.\n>>\n>> This\n>>\n>> https://www.phoronix.com/news/GNU-Glibc-arc4random-Functions\n>>\n>> was the first hit of my search in the area, but I think you are\n>> referring to\n>>\n>> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=eaad4f9\n>>\n>> that happened 5 days after the thing got in and the code there tells\n>> me that your summary of the situation is quite accurate.\n>>\n>> So I agree that dropping this patch makes sense, but do we want to\n>> do a bit more to improve the situation?\n>>\n>> Here is an attempt to improve what we have in Makefile (and possibly\n>> the Linux section in config.mak.uname, but that is improving what we\n>> do not have) to tell folks that arc4random in glibc is only for\n>> compatibility and they should pick getrandom() until the situation\n>> changes.\n>>\n>> --- >8 ---\n>> Subject: config/Makefile: a note on CSPRNG_METHOD choice for Linux\n>>\n>> arc4random() was added to glibc in July 2022, but quickly replaced\n>> by a stub implementation that wraps around getrandom(). Hence there\n>> is no actual benefit to calling arc4random() over getrandom() on\n>> glibc based systems, at least for now.\n>>\n>> To avoid enticing Linux users to choose arc4random(), leave a note\n>> that their arc4random() in glibc is not the same as what their\n>> friends use on other platforms, and guide them to use getrandom()\n>> instead in the meantime.\n> \n> Makes me wonder whether we should also change the order in which Meson\n> auto-detects functions. That is, do we want the following patch that\n> favors getrandom over arc4random?\n> \n\nThat was my immediate thought also. :)\n\nATB,\nRamsay Jones\n\n\n"},{"id":"514715","messageId":"Z9ulomq1tDrZRsmL@pks.im","threadId":"63130","inReplyTo":"74b2838e-1d7b-4ee0-a4a7-e3d21f4e6597@ramsayjones.plus.com","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-03-20T05:20:34Z","receivedAt":"2025-03-20T05:20:39Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Mar 20, 2025 at 01:28:31AM +0000, Ramsay Jones wrote:\n> \n> \n> On 19/03/2025 13:30, Patrick Steinhardt wrote:\n> > On Sun, Mar 16, 2025 at 01:41:40PM -0700, Junio C Hamano wrote:\n> >> \"brian m. carlson\" writes:\n> >>\n> >>> When arc4random was added to glibc, the Linux kernel CSPRNG maintainer\n> >>> argued that it was not a secure approach (I disagree), and convinced the\n> >>> glibc maintainers to just make it a wrapper around the Linux kernel\n> >>> CSPRNG, which it now is. So there's no actual benefit to calling\n> >>> arc4random versus getrandom, and since it's newer and less commonly\n> >>> available than getrandom, as well as slightly slower (because of an\n> >>> extra function call), getrandom should be preferred.\n> >>\n> >> This\n> >>\n> >> https://www.phoronix.com/news/GNU-Glibc-arc4random-Functions\n> >>\n> >> was the first hit of my search in the area, but I think you are\n> >> referring to\n> >>\n> >> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=eaad4f9\n> >>\n> >> that happened 5 days after the thing got in and the code there tells\n> >> me that your summary of the situation is quite accurate.\n> >>\n> >> So I agree that dropping this patch makes sense, but do we want to\n> >> do a bit more to improve the situation?\n> >>\n> >> Here is an attempt to improve what we have in Makefile (and possibly\n> >> the Linux section in config.mak.uname, but that is improving what we\n> >> do not have) to tell folks that arc4random in glibc is only for\n> >> compatibility and they should pick getrandom() until the situation\n> >> changes.\n> >>\n> >> --- >8 ---\n> >> Subject: config/Makefile: a note on CSPRNG_METHOD choice for Linux\n> >>\n> >> arc4random() was added to glibc in July 2022, but quickly replaced\n> >> by a stub implementation that wraps around getrandom(). Hence there\n> >> is no actual benefit to calling arc4random() over getrandom() on\n> >> glibc based systems, at least for now.\n> >>\n> >> To avoid enticing Linux users to choose arc4random(), leave a note\n> >> that their arc4random() in glibc is not the same as what their\n> >> friends use on other platforms, and guide them to use getrandom()\n> >> instead in the meantime.\n> > \n> > Makes me wonder whether we should also change the order in which Meson\n> > auto-detects functions. That is, do we want the following patch that\n> > favors getrandom over arc4random?\n> > \n> \n> That was my immediate thought also. :)\n\nOkay. Will you pick it up in v2 of this patch series?\n\nThanks!\n\nPatrick\n"},{"id":"514780","messageId":"3267c1be-5749-4220-90d8-22aabb631823@ramsayjones.plus.com","threadId":"63130","inReplyTo":"Z9ulomq1tDrZRsmL@pks.im","subject":"Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-03-20T16:41:16Z","receivedAt":"2025-03-20T16:41:20Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 20/03/2025 05:20, Patrick Steinhardt wrote:\n[snip]\n>> That was my immediate thought also. :)\n> \n> Okay. Will you pick it up in v2 of this patch series?\n\nHeh, well, that was my immediate thought, but having thought\nsome more, and considering Brian's earlier email response, I\nhave thought again. ;)\n\nWithout a wholesale change to the logic (in order to make it\nplatform siloed), it is probably best to just set the Linux\ndefault to 'getrandom'. (I can override in config.mak for my\ntests, or just ignore that difference now I know :) ).\n\nThe issue is that each platform has a different priority order\nfor the 'backends' (even multiple orders depending on the\ncriteria, eg. availability, performance), so the current order\nis probably fine on newer Linux systems. However, to cater to\nolder systems, it would be best to default to getrandom.\n\n[Note cygwin and *BSD systems should prefer arc4random, on Linux\nall of the three main options (arc4random, getrandom, getentropy)\nare pretty much the same from a performance perspective, but\ngetrandom is much more 'available'].\n\nSo, yes, a v2 of the series, but a different final patch.\n\nATB,\nRamsay Jones\n\n"}]}