On Mon, Jun 27, 2022 at 06:31:41PM -0700, Vagrant Cascadian wrote:
> 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

I looked back at the original email. I think we should not embed a
static random prime and mark it as non-substitutable. Then with that
flag add a note that it generates a prime during building and everyone
having a unique prime is more important to us than everyone having the
same reproducible prime.


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