[tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
-------------------------------------------+-------------------------------
 Reporter:  mttp                           |          Owner:  (none)
     Type:  project                        |         Status:
                                           |  needs_revision
 Priority:  Medium                         |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------

Comment (by JeremyRand):

 Hi @gk, thank you for the review.

 > 1) We should start to get the compiler related things right. I don't
 understand why you need to add a gcc-cross project in addition to the gcc
 project. Cross-compiling GCC so it is usable for a given target should
 just get included in the gcc project both in its config and build file I
 think.

 The reasoning here was that building a GCC cross-compiler is somewhat more
 complex than building a non-cross GCC, because with a non-cross-compiler,
 the C/C++ standard libraries shipped with Debian are sufficient, whereas
 building a cross-compiler requires building the C/C++ standard libraries
 from source.  I therefore suspected that patching the gcc project to build
 the C/C++ standard libraries would be considered too invasive, and I
 instead opted for adding a gcc-cross project so that, if it broke
 anything, the breakage would be isolated to the linux-arm target instead
 of all linux targets.  I intended to submit a follow-up patch that made
 all linux targets use gcc-cross once that code had gotten some more
 testing by the community.  That said, if you're comfortable simply adding
 that functionality to the gcc project, then I have no objection to doing
 so as part of this patch rather than as a follow-up patch later.  (Who
 knows, building the standard C/C++ library from source might yield
 improvements in reproducibility and resistance to supply-chain attacks, so
 it may be a good thing.)

 > 2) Why do we have a var/linux-cross + a var/linux-arm target? It seems
 it would be worthwhile to stick to the OS-arch pattern and if we think we
 want to generate a more abstract target later on that's easily doable
 (like we have e.g. var/linux and var/linux-x86_64 defined already to have
 the option to apply general things to all the Linux arches and have arch-
 specific things, though)

 The motivation here was so that the x86 targets could use gcc rather than
 gcc-cross; see above.  Given that you're okay with moving the gcc-cross
 changes into gcc, I'm pretty sure we can get rid of the linux-cross
 target.

 > 3) Allowing networking during the build part does not fly. What are the
 needs for that?

 I agree that this is a very bad thing and isn't mergeable.  The motivation
 here is that Firefox requires some libraries (for the target arch) which
 tor-browser-build doesn't currently build from source; tor-browser-build
 instead installs the -dev package from Debian.  Unfortunately, the armhf
 versions of some of those -dev packages conflict with critical libraries
 for the x86_64 arch (I seem to recall that apt-get would uninstall the
 x86_64 C/C++ standard libraries in order to install those armhf -dev
 packages).  So, as a workaround, I used "apt-get download" in the build
 script to obtain the armhf packages without installing them, and then
 extract them to a folder that I pointed the Firefox configure script to.
 Using apt-get download inside the build script was not intended to be a
 final solution, it was simply the easiest way to continue making progress
 at making it build at all, and I intended to find a better solution prior
 to a merge.

 Anyway, I *think* a suitable way to do this would be for the container-
 image project to support downloading packages via apt-get download without
 installing them.  Then it could expose their paths to the Firefox build
 script via an rbm variable or an env variable, and Firefox's build script
 could extract them without needing to run apt-get download inside the
 Firefox build script.  Do you think this is the right way to do it, or is
 there another approach you'd prefer?  (I've never done any hacking on the
 container-image project, so it might take me some time to get this
 working, but I'm reasonably confident I can do it.)

 One other suitable way to do this would be for rbm to support "apt-get
 download" as a way of getting input files, similar to "git clone" and
 HTTP(S) downloads as are already supported.  Is adding this to rbm
 feasible?  (Maybe it's already supported and I just never ran across that
 functionality?)  If we can do that, that may be better than messing with
 container-image, since that way we avoid needing to create a new image
 that uses up additional storage.  Curious what you think the most
 desirable approach here is.

 > 4) FTE is going away soon, just ignore it (and set the fteproxy switch
 in rbm.conf in the meantime). It's fine to ignore snowflake for now, too.
 There is a snowflake switch you can set in rbm.conf as well.

 Okay, I can do that.

 > 5) Could you clean up your patches substantially and reorder them, so
 that you maybe have patches per project? It's hard to give more fine-
 grained feedback otherwise.

 Yes, I can do that.  One commit per project seems like a good way to
 divide up the changes.

 > 6) It's fine planning with GCC 7.4.0 we are close to switch to a newer
 one than 6.4.0 (although I am not sure yet whether we should make use of
 GCC 8 while we are at it). You should remove your binutils related hacks
 as we now are on 2.31.1.

 Okay, sounds good.  Do you prefer GCC 7.4.0 or 7.3.0?  My patch switches
 to 7.3.0 since that was the one that someone from the Mozilla Bugzilla
 thread said definitely worked.  I'd have no objection to trying 7.4.0, or
 8, if you want that (though since I haven't tested those versions, I have
 no idea whether it will introduce new bugs).

 > I wonder, generally, whether we should call the OS-arch combination
 linux-armhf here instead of just linux-arm, following Debian (especially
 as we might want to support 64-bit as well in the future).

 armhf sounds good to me.

 Thank you again for the review, this gives me some useful direction as I
 continue making the patch more suitable for a merge.

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