[tor-bugs] #10599 [Tor bundles/installation]: Investigate building TBB with SoftBound or AddressSanitizer

[Tor Bug Tracker & Wiki]

#10599: Investigate building TBB with SoftBound or AddressSanitizer
------------------------------------------+--------------------------------
     Reporter:  mikeperry                 |      Owner:  erinn
         Type:  enhancement               |     Status:  new
     Priority:  major                     |  Milestone:
    Component:  Tor bundles/installation  |    Version:
   Resolution:                            |   Keywords:  gitian, tbb-
Actual Points:                            |  security
       Points:                            |  Parent ID:
------------------------------------------+--------------------------------

Comment (by gk):

 Replying to [comment:21 mikeperry]:
 > gk - I have three thoughts about getting this out the door quicker in
 the best shape possible:
 >
 > 1. Screw lucid. Let's only support x64 and Precise+ with these builds.
 Build 4.9.0 and the ASAN+Ubsan+VTV firefox in Precise, and don't worry
 about that 4.9.0 compile error. (Though I guess this means we can't use
 the gitian-utils descriptors as-is to build this compiler with the rest of
 the tools..).

 We are not only throwing lucid but debian stable and presumably other
 distros as well out of the boat. So I'd rather avoid that at the moment if
 possible. Re: re-using descriptors: I wouldn't worry about that much
 currently as we need a separate hardening-branch anyway (e.g. we don't
 build 32bit bundles as this breaks etc.).

 > 2. Don't strip it, so stacktraces like the cyperpunks one in comment:16
 make sense immediately without the need to make a second set of detached
 debug symbols for this build. This way we don't hit #12103 either, and
 hopefully all of the other hardening options will remain in-tact too.
 >
 > 3. Install all Firefox langpack locales in one build. This way we don't
 have to ship 12 versions of this huge build. We can provide instructions
 for users on how to switch their language for now, and perhaps later add a
 Tor Launcher or other UI option to select locale for these builds.

 Hrm... I am not a fan of this idea for a couple of reasons:
 0) We need to fix #12103 anyway for non-hardened builds.
 1) Users have to download a huge build (e.g. the debug symbols file alone
 is twice as big with ASan) which might deter from testing/using it.
 2) We need to provide additional instructions and/or a Tor Launcher patch
 that both need to be maintained.
 3) (and this one is the most important to me) There might be cases where a
 stacktrace alone is not helpful for debugging, i.e. cases where we want
 things --enable-debug and --disable-optimize (and maybe others) give us.

 > Thoughts? I suppose an alternate way to achieve #1 might be to build a
 4.8 gcc in lucid and then use that gcc to build 4.9. Not sure which would
 mean more build time/hassle on average.

 I slightly prefer that approach to #1 if we don't find a better solution.
 It needs *once* more build time as we save the built utils (but this build
 time overhead can be quite a lot as we need to compile both gccs with -j1
 due to autotools not liking libfaketime). Anyway, I've filed
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 and maybe the gcc folks
 are coming up with an easy fix/workaround for us.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10599#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online