guix-devel
[Top][All Lists]
Advanced

[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: Efraim Flashner
Subject: Re: maradns reproducibility fixes and the merits of picking a random number
Date: Wed, 8 Jun 2022 14:47:27 +0300

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 <felix.lechner@gmail.com> 
> wrote:
> >Hi,
> >
> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian
> ><vagrant@reproducible-builds.org> 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¹.

> >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.

> >
> >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?
> >
> >Thank you for your hard work on Guix! As a newbie I'll say, what a
> >great distro. Thanks, everyone!
> >
> >Kind regards,
> >Felix Lechner
> >
> >[1] https://maradns.samiam.org/
> >
> 

¹ https://xkcd.com/221/

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature


reply via email to

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