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.lech...@gmail.com> wrote: > >>>> >On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian > >>>> ><vagr...@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 <efr...@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
signature.asc
Description: PGP signature
