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 >> <felix.lech...@gmail.com> wrote: >> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian >> ><vagr...@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¹. ... > ¹ https://xkcd.com/221/
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 upstream... Thoughts? >> >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, vagrant
signature.asc
Description: PGP signature