git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  "Randall S. Becker" <randall.becker@nexbridge.ca>
Subject: Re: [PATCH 2/2] reftable/stack: accept insecure random bytes
Date: Tue, 07 Jan 2025 13:03:26 -0800	[thread overview]
Message-ID: <xmqqv7uqqqu9.fsf@gitster.g> (raw)
In-Reply-To: <xmqqzfk2qr62.fsf@gitster.g> (Junio C. Hamano's message of "Tue, 07 Jan 2025 12:56:21 -0800")

Junio C Hamano <gitster@pobox.com> writes:

> Yet a platform replaces it with a function that returns an error or
> aborts?  What kind of nonsense is that?  Do we really need to cater
> to such an insanity?
>
> Use of git_rand() here goes backwards against the more recent trend
> in reftable/ directory to wean the code off of the rest of Git by
> getting rid of unnecessary dependency, doesn't it?
>
> I think [PATCH 1/2] makes sense regardless, though.  But shouldn't
> we be pushing back this step, with "fix your rand(3)"?
>
> Thanks.

Ah, I misread the patch.  It has two hunks, and what I said applies
to the earlier one, but the later one is already contaminated with
git_rand(), and that is what is failing, i.e. it is not a nonsense
platform replacing rand() with something that can fail.

It may still make sense to drop the first hunk, and consider how to
proceed when you further want to reduce the unnecessary dependencies
for external users of the reftable library, though.  Are there
correctness implications if git_rand() in format_name() yields non
random results (like, always using "rnd = 0" instead of calling
git_rand())?  I seriously hope not.  And if there is no correctness
implications, perhaps we can replace it with rand() or even constant
"0"?

Thanks.

>> Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
>> Signed-off-by: Patrick Steinhardt <ps@pks.im>
>> ---
>>  reftable/stack.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/reftable/stack.c b/reftable/stack.c
>> index 6d0aa774e7e29d5366ed55df19725944f8eef792..572a74e00f9ed6040534e060652e72c26641749d 100644
>> --- a/reftable/stack.c
>> +++ b/reftable/stack.c
>> @@ -493,7 +493,7 @@ static int reftable_stack_reload_maybe_reuse(struct reftable_stack *st,
>>  		close(fd);
>>  		fd = -1;
>>  
>> -		delay = delay + (delay * rand()) / RAND_MAX + 1;
>> +		delay = delay + (delay * git_rand(CSPRNG_BYTES_INSECURE)) / UINT32_MAX + 1;
>>  		sleep_millisec(delay);
>>  	}
>>  
>> @@ -659,7 +659,7 @@ int reftable_stack_add(struct reftable_stack *st,
>>  static int format_name(struct reftable_buf *dest, uint64_t min, uint64_t max)
>>  {
>>  	char buf[100];
>> -	uint32_t rnd = (uint32_t)git_rand(0);
>> +	uint32_t rnd = git_rand(CSPRNG_BYTES_INSECURE);
>>  	snprintf(buf, sizeof(buf), "0x%012" PRIx64 "-0x%012" PRIx64 "-%08x",
>>  		 min, max, rnd);
>>  	reftable_buf_reset(dest);

  parent reply	other threads:[~2025-01-07 21:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-07 15:26 [PATCH 0/2] reftable/stack: stop dying on exhausted entropy pool Patrick Steinhardt
2025-01-07 15:26 ` [PATCH 1/2] wrapper: allow generating insecure random bytes Patrick Steinhardt
2025-01-07 15:27 ` [PATCH 2/2] reftable/stack: accept " Patrick Steinhardt
2025-01-07 15:37   ` rsbecker
2025-01-07 20:56   ` Junio C Hamano
2025-01-07 21:03     ` rsbecker
2025-01-07 21:09       ` Junio C Hamano
2025-01-07 21:03     ` Junio C Hamano [this message]
2025-01-08  6:51       ` Patrick Steinhardt
2025-01-08 15:39         ` Junio C Hamano
2025-01-08 16:21           ` Patrick Steinhardt
2025-01-08 17:40             ` Junio C Hamano
2025-01-08 18:16               ` Patrick Steinhardt
2025-01-07 23:56   ` rsbecker
2025-01-07 23:21 ` [PATCH 0/2] reftable/stack: stop dying on exhausted entropy pool brian m. carlson
2025-01-07 23:54   ` rsbecker
2025-01-08  7:18     ` Patrick Steinhardt
2025-01-08 13:50       ` rsbecker
2025-01-08 22:44       ` 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=xmqqv7uqqqu9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    --cc=randall.becker@nexbridge.ca \
    /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).