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

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

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

On 2022-06-22, Vagrant Cascadian wrote:
> On 2022-06-08, Vagrant Cascadian wrote:
>> 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.lechner@gmail.com> wrote:
>>>> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian
>>>> ><vagrant@reproducible-builds.org> wrote:
>>> 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?
>
> Should I just push that part for the short-term workaround? Or does
> someone else want to push that?
>
>
>>>> >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...
>
> And, this was the best place I found to mention this issue upstream,
> will see what kind of response I get:
>
>   https://github.com/samboy/MaraDNS/discussions/101#discussioncomment-3006487

Upstream appears to think it is mostly ok to actually embed a specific
random prime... and not have it be different across all the builds, as
the number is mixed with other randomness from /dev/urandom.

It is expensive to generate the random prime on some hardware, so doing
so at runtime might not be feasible in some cases...

So, where do we go from here, knowing what we now know? :)


live well,
  vagrant

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