[tor-bugs] #25481 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds on Linux with Rust enabled

[Tor Bug Tracker & Wiki]

#25481: Ship tor in Tor Browser nightly builds on Linux with Rust enabled
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201804,          |  Actual Points:
  boklm201804, TorBrowserTeam201804R             |
Parent ID:  #25220                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):

 * keywords:  tbb-rbm, GeorgKoppen201804, boklm201804, TorBrowserTeam201804
     => tbb-rbm, GeorgKoppen201804, boklm201804, TorBrowserTeam201804R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:9 boklm]:
 > Replying to [comment:6 gk]:
 > > So, I worked around that by building LLVM during the rust compilation
 (which make the whole process taking significantly more time) using that
 version in turn.
 >
 > I don't see LLVM being built in your patch. Is it done internally by the
 rust build system?

 Yes, it uses the LLVM code that is shipped with the Rust source.

 > The extracting of gcc and update of the PATH/LD_LIBRARY_PATH could be
 replaced by:
 > {{{
 > [% pc('gcc', 'var/setup', { compiler_tarfile =>
 c('input_files_by_name/gcc') }) %]
 > }}}
 > However it will also set hardened-cc links. Is it because the build
 doesn't work with hardened-cc that you didn't use it?

 No, I originally wanted to avoid using our own GCC as this adds complexity
 but piece by piece I realized that this is not realistic and added
 workaounds which resulted in the final patch, forgetting about this macro.
 This is fixed now.

 > For the `ln -s gcc cc` link, I am wondering if we should add it directly
 in `projects/gcc/build`, or if there are cases where we might not want
 this link.

 I can avoid this clumsy symlink by using a configure option which seems
 neat and which we probably need to use anyway when actually cross-
 compiling. So, I think we should go with that.

 > In `projects/tor/build`, I think the lines after the `IF c("var/linux")
 && c("var/nightly")` can be indented.

 Fixed.

 The updated patch is at `bug_25481_v4`
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_25481_v4&id=fde93d07ca425ee884930cf01fd435b31ace48b8)
 in my public `tor-browser-build` repo. Note: I tested the x86_64 tor and
 it is running fine for me. I even checked whether tor built from the same
 revision twice is identical, and it is! Moreover, I verified that the
 hardening properties on the tor binary are still the ones we want to have
 (with the checksec script). So, we are good here. I guess the 32bit tor
 could get tested, though, which I did not do yet.

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