[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: Wed, 08 Jun 2022 13:33:18 -0700

On 2022-06-08, Efraim Flashner wrote:
> On Tue, Jun 07, 2022 at 07:20:25AM +0200, Julien Lepiller wrote:
>> On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner 
>> <> wrote:
>> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian
>> ><> wrote:
>> >>
>> >> So, Debian's maradns package just removes this embedding of a "random"
>> >> number, and I've basically adapted their patches to build reproducibly
>> >> on guix too... by basically embedding the same "random" number every
>> >> single build!
> I have to say I was shocked to not see 4 as the random number¹.
> ¹

In an alternate reality, I did consider 4 for the reasons you alluded
to, but ruled it out because it was not a random prime number. :)

>> >There may be more than one opinion, but as the maintainer of a TLS
>> >library in Debian I think it is a questionable tradeoff. At a minimum,
>> >it would be preferable to use the version number instead of a fixed
>> >constant for all releases.
>> Consider that even without the patch, each distro will build maradns once 
>> and distribute the package to their user. Every user gets the same binary 
>> with the same "random" number. So even if it's chosen at build time, it 
>> won't really help.
>> In our case, it only means users who don't use substitutes get a random 
>> number, others get the same number that the build farm picked at random. 
>> Fixing a number doesn't sound like it's gonna change a lot for these users.
> This is something we can work with. We can just mark the package as
> '#:substitutable? #f' and then everyone will have to build it
> themselves. It still won't really be reproducible, but everyone will
> actually have their own special random number.

This actually seems like the best approach in the short term! Leaving
time to work out a better fix long-term, probably by working with


>> >MaraDNS does not support DNSSEC so the program may not use entropy for
>> >keys. Either way, I'd rather use an unreproducible build than,
>> >accidentally, a known number series to encrypt secrets. Can one patch
>> >out the constant entirely so it is no longer available?
>> >
>> >The upstream website says: "People like MaraDNS because it’s ...
>> >remarkably secure." [1] Since many distributions have the same issue,
>> >upstream could perhaps offer the patch as a build switch to enable a
>> >build-time seed only when needed.
>> Sounds like the safest option. Maybe we could change the code that uses that 
>> number to naise an exception or abort?

Yeah, seems worth taking this or similar ideas upstream...

live well,

Attachment: signature.asc
Description: PGP signature

reply via email to

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