Upstream here: No, you can not remove this functionality without affecting security. Deadwood uses a "home grown" unpredictable hash compression scheme; the more that the numbers are unpredictable, the better.
If making the build process consistent is needed, feel free to edit the Makefile to not rebuild the hash compression multiply constant (the Windows Makefile is a good starting point to see how to do this). To make the hash compression function more secure, it's possible to replace it by SipHash. I will not do this myself (MaraDNS/Deadwood was declared feature complete before SipHash existed), but I do have a SipHash implementation that someone making a third-party fork of Deadwood: http://samiam.org/blog/20131006.html - Sam On Sun, May 17, 2015 at 8:15 AM, Reiner Herrmann <rei...@reiner-h.de> wrote: > Source: maradns > Version: 2.0.09-4 > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: randomness > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Hi! > > the deadwood binary can currently also not be built reproducibly. > During building a new header DwRandPrime.h is generated with > the tool RandomPrime, which is used in the deadwood source. > > Is there any reason why the MUL_CONSTANT has to differ on each build? > Or could this also be made reproducible without affecting security? > > Regards, > Reiner > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
