On Thu, Jan 05, 2012 at 02:52:42PM +0100, Jacob Appelbaum wrote: > On 01/05/2012 02:50 PM, Paul Syverson wrote: > > Hi Jake, > > > > On Thu, Jan 05, 2012 at 12:15:08PM +0100, Jacob Appelbaum wrote: > >> Hi, > >> > >> A few Tor hackers are meeting today to discuss build engineering issues > >> and we'd like to start a thread on deterministic builds. > >> > >> We believe that Windows and Mac OS X both produce build results that are > >> extremely difficult to verify. On Gnu/Linux sometimes the build results > >> are difficult to verify. > >> > >> If anyone has thoughts on the matter, we'd love to hear how Tor as a > >> project should tackle verifiable builds of the various software we ship. > >> > > > > I'm replying just to you. If it's a dumb reply or something already > > well in hand you can just tell me, and I won't have induced a flood > > of noise on tor-talk. But if you think I'm asking something that is > > worth discussing there, feel free to answer on tor-talk and include > > my question there. > > > > I know only minimally about the area, but does build diversity help > > at all to address monoculture issues in attacks the way that memory > > randomization and source code diversity do? I understand that it is > > good to have determinsitic builds for verification and I'm guessing > > that even if the answer is yes, the tradeoff is worth it overall. I > > just think it's good to be fully aware of the tradeoffs being made. > > Heya Paul, > > Good thought! > > In theory, we should get memory space randomization at run time and not > at build time. Part of the problem is that some build environments > actually put a time stamp into the binary or something similarly > annoying. We want to defend against build machines being compromised and > to allow others to verify that their builds are correct or that ours are > a mess. >
I understand that memory space randomization is a runtime thing. And I understand why we want verification. I also understand how version diversity is a "codetime" thing used in general to guard against monoculture in a related but distinct way from ASLR etc. (and that Tor does not currently bother to do version diversity, and that it is a tradeoff probably not worth making). What I was asking about was whether there is anything to be _gained_ by the use of build diversity, either by adding yet another defense for the multiple issues of software monoculture or something else. Probably like n-version programming, etc. it is not a worthwhile tradeoff, but I didn't know if this was a topic that had already been broached. It's better to consciously reject a tradeoff than to be unaware of it. You didn't immediately dismiss my question, so I'm cc-ing tor-talk (so if you now get what I was asking, you can tell me it is dumb in public ;>). aloha, Paul _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
