[Top][All Lists]

[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 <> 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,

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]