[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: maradns reproducibility fixes and the merits of picking a random num
From: |
Vagrant Cascadian |
Subject: |
Re: maradns reproducibility fixes and the merits of picking a random number |
Date: |
Tue, 28 Jun 2022 09:33:48 -0700 |
On 2022-06-28, Gábor Boskovits wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> ezt írta (időpont: 2022. jún. 28., K
> 18:07):
>> Vagrant said:
>> > It is expensive to generate the random prime on some hardware, so doing
>> > so at runtime might not be feasible in some cases...
>>
>> But in the same reply you're paraphrasing, upstream also says:
>>
>> > In 2010, I updated that homegrown hash compression
>> > algorithm to also add a random number when compressing
>> > the input, and calculating another 32-bit random number
>> > when Deadwood starts.
>> ^^^^^^^^^^^^^^^^^^^^^^^
>>
>> and
>>
>> > I believe the hash compression algorithm is protected from hash
>> > bucket collision attacks, even if Deadwood is patched to make
>> > MUL_CONSTANT a constant number, since the add constant
>> > remains random.
>>
>> so their 'too computationally expensive' does not make sense to me. Do
>> they bail out if generating the truly random part 'takes too long'? Surely
>> not.
>>
>> Neither does the 'ah, but your urandom might be broken' argument for
>> silently substituting a still less random number.
Yeah, the response was a bit confusing to me, at least. :)
>> I don't think this alone justifies the scheme, or disabling substitutes.
I am at a loss as to what to do then ... nothing and just have it be
unreproducible? embed a specific random number? come up with better
upstreamable patches?
> I tend to agree.
> Afaics this can be solved in a workaround way. I don't think this random
> number is picked up by the build in any way.
What do you mean? The whole reason I discovered this issue is that it
embeds a random number in the build, making it not build reproducibly...
> Upstream could just provide it as an optional config value. That would
> be better in every respect. Then they could just give a build flag to
> move to the new model.
That sounds reasonable to me...
> Do you think such a proposal would be accepted upstream?
I hope something better would be accepted upstream, but I don't myself
use maradns, and have a grand total of precisely one interaction with
maradns upstream so far... :)
live well,
vagrant
signature.asc
Description: PGP signature
- Re: maradns reproducibility fixes and the merits of picking a random number, (continued)
- Re: maradns reproducibility fixes and the merits of picking a random number, Efraim Flashner, 2022/06/08
- Re: maradns reproducibility fixes and the merits of picking a random number, Vagrant Cascadian, 2022/06/08
- Re: maradns reproducibility fixes and the merits of picking a random number, Vagrant Cascadian, 2022/06/22
- Re: maradns reproducibility fixes and the merits of picking a random number, Vagrant Cascadian, 2022/06/27
- Re: maradns reproducibility fixes and the merits of picking a random number, Efraim Flashner, 2022/06/28
- Re: maradns reproducibility fixes and the merits of picking a random number, Jack Hill, 2022/06/28
- Re: maradns reproducibility fixes and the merits of picking a random number, Tobias Geerinckx-Rice, 2022/06/28
- Re: maradns reproducibility fixes and the merits of picking a random number, Gábor Boskovits, 2022/06/28
- Re: maradns reproducibility fixes and the merits of picking a random number,
Vagrant Cascadian <=
- Re: maradns reproducibility fixes and the merits of picking a random number, Tobias Geerinckx-Rice, 2022/06/28
- Re: maradns reproducibility fixes and the merits of picking a random number, Tobias Geerinckx-Rice, 2022/06/28
Re: maradns reproducibility fixes and the merits of picking a random number, Ludovic Courtès, 2022/06/07
Re: maradns reproducibility fixes and the merits of picking a random number, Arun Isaac, 2022/06/08
Re: maradns reproducibility fixes and the merits of picking a random number, Liliana Marie Prikler, 2022/06/08