That's a good idea. Also, please let me know if I can have my turn on Sunday.
On Fri, Mar 9, 2018 at 12:06 PM Andrew Miller <soc1...@illinois.edu> wrote: > 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 >
