Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian <vagrant@reproducible-builds.org>]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]