If there is a free slot on March 12 —13 Emea timezone I am happy to do a contribution with an alternate implementation (I took part earlier) Gabor
On Mar 9, 2018 11:23 PM, "Devrandom via zapps-wg" <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 >> >
