What if we just reach out to everyone currently in queue and ask them to use the golang version (and save the binaries)
On Fri, Mar 9, 2018 at 2:57 PM, Devrandom <c1.devran...@niftybox.net> wrote: > I can take care of the first bullet point (hopefully on ARM64), but would > be nice if we had more than one additional round with golang. > > > On Fri, Mar 9, 2018 at 11:22 AM Andrew Miller <soc1...@illinois.edu> > wrote: > >> It sounds like an efficient way to dispense with the suggestions >> Devrandom raised are to: >> 1. Do a round with the deterministic Go build, explicitly saving the >> binary for posthoc analysis, and ideally running it on a non x86 >> architecture if anyone has one... >> 2. Do a round with mrustc >> What would it take to get a concrete plan to include those? >> >> On Fri, Mar 9, 2018 at 2:17 PM, Sean Bowe <s...@z.cash> wrote: >> >>> As far as security goes, we've successfully guarded against all but >>> the most elaborate and unrealistic attack scenarios. The remaining >>> threats require some combinatorial explosion of individually >>> sophisticated attacks or breakthroughs, like stealthy backdoors in the >>> Rust compiler and still for many participants to be colluding in >>> secret, somehow without leaving evidence behind. >>> >>> We don't need an absolutely perfect ceremony to get strong privacy >>> guarantees, we get that already even with a totally compromised >>> ceremony. We *could* continue to invest time and resources for many >>> more months or years in order to make us marginally more resistant to >>> these absurd attack scenarios, but by the time we'd be finished with >>> the ceremony we'll probably have better proving systems available >>> anyway. It's silly to let privacy languish in the meantime. >>> >>> I think we did the best with the time we had, but if you disagree, >>> remember that all of this can be extended and improved by anyone, even >>> after this ceremony is done! >>> >>> Sean >>> >> >>> On Fri, Mar 9, 2018 at 11:06 AM, Peter Todd <p...@petertodd.org> wrote: >>> >> > On Fri, Mar 09, 2018 at 04:49:37PM +0000, Devrandom wrote: >>> >> Hi all, >>> >> >>> >> I have some concerns about the lack of diversity of contributions: >>> >> >>> >> - most (all?) of the contributions used a distributed Rust toolchain, >>> which >>> >> suffers from the "trusting-trust" issue since they are >>> self-compiled. I >>> >> don't think I've seen any contributions using the mrustc build path. >>> >> - there were very few contributions (two?) using the golang >>> implementation >>> >> - no attempt has been made to replicate the deterministic golang build >>> >> - people did not capture the binary they used, so we can't do >>> forensics in >>> >> case of future questions >>> >> - there were no contributions using alternative processor >>> architectures >>> >> (e.g. ARM64). I believe this is possible using the golang >>> implementation. >>> >> - there was a lot of focus on destroying toxic waste and not enough >>> on the >>> >> trustworthiness of the tools >>> > >>> > I agree with all these points, particularly the latter: we should be >>> focused on >>> > genuine security, not flashy marketing stunts. (indeed, I regret the >>> way my own >>> > participation was marketted the last time around) >>> > >>> > -- >>> > https://petertodd.org 'peter'[:-1]@petertodd.org >>> >> >> -- >> Andrew Miller >> University of Illinois at Urbana-Champaign >> > -- Andrew Miller University of Illinois at Urbana-Champaign
