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
