Make rust code in ESR 52 proxy safe
Even though we don't use any Rust in ESR 52 we should get rid of proxy bypassing calls for safety and to remind us for later:
third_party/rust/url/src/host.rs has a to_socket_addrs and ToSocketAddrs methods.
Activity
bug_21862(https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_21862&id=44fc4b2675d36b79d6d0cf374d4fcc74aebb1f1f) has a patch for review.Trac:
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201705R added
Status: new to needs_reviewI don't know rust either, but I was curious what happens if these functions are ripped out. Is any code calling them?
I tried building with
ac_add_options --enable-rustin the mozconfig file and I got the follow error message:2:45.75 error: the listed checksum of `/home/arthur/tor-browser/third_party/rust/url/src/lib.rs` has changed: 2:45.75 expected: c3542aabc733f76a3b9c7d24b5c41e60e9eb84d2712660611300d1de0e7c2072 2:45.75 actual: 3abae55faf84f05be573d6275fa49ca2e61a4a95e3717a9059e3971b5d53101a 2:45.75 2:45.75 directory sources are not intended to be edited, if modifications are required then it is recommended that [replace] is used with a forked copy of the source 2:45.76 /home/arthur/tor-browser/config/rules.mk:939: recipe for target 'force-cargo-build' failed 2:45.76 make[5]: *** [force-cargo-build] Error 101 2:45.76 /home/arthur/tor-browser/config/recurse.mk:71: recipe for target 'toolkit/library/rust/target' failed 2:45.76 make[4]: *** [toolkit/library/rust/target] Error 2 2:45.76 make[4]: *** Waiting for unfinished jobs....The "expected" hash (c3542aab...) is located in
third_party/rust/url/.cargo-checksum.json. The README in the same directory says this code is aURL library for Rust, based on the [URL Standard](https://url.spec.whatwg.org/).So it looks to me like this is patching a "third-party library", whereas we should probably be ripping out something considered to be "first-party" gecko code.
Another option might be just to remove the whole third-party directory or even all rust files from the source code.
-
Replying to arthuredelstein:
So it looks to me like this is patching a "third-party library", whereas we should probably be ripping out something considered to be "first-party" gecko code.
Another option might be just to remove the whole third-party directory or even all rust files from the source code.
I think that is a good reminder of what we need to think about once building Rust parts is mandatory as this is different from the way we handled a lot of our proxy-bypass-(in-depth)-defenses so far. I think just for the sake of having those calls out of esr52 the current approach still seems to be sufficient. And if you can't get the stuff even compiled right now, even better. :) Thus, I take it as-is.
Applied to
tor-browser-52.1.1esr-7.0-1andtor-browser-52.1.0-7.0-2(commit 78aa6185cd8d1d11e09495f6e4dc5cbc19e80cba and 88c25c56d96f8fc0801359358d808f0d0e7d4b93) with a changed commit message pointing out that we probably need a more elaborate approach once we compile with Rust enabled.Trac:
Status: needs_review to closed
Resolution: N/A to fixed 
In the next ESR (and already in the current release),
--enable-rustwill not exist.When we say "third party" code it means vendored dependencies necessary for building Firefox that are not directly maintained in the mozilla-central repo. This is not something that can/should be ripped out. Currently, the third_party directory is only used for vendored Rust dependencies, however other vendored code may move there in the future.
In fact, rust-url is maintained by Servo, which is a Mozilla project. However, there are other crates under third_party which are not maintained by Mozilla. We intend to do some auditing before shipping. The currently shipping crates are all maintained by the Servo or Rust projects.
Currently (as of a recent nightly), the Rust code in mozilla-central consists of:
- The mp4 parser. Enabled by default. Should not hit the network.
- Stylo (enabled recently); servo's style system in Firefox. Built by default, preffed off , planned to be preffed on on 57. Can be disabled; is a large chunk of code. May become mandatory a few release cycles after 57. This should not hit the network on its own, we thread through Gecko networking code.
- Webrender. Built by default, preffed off. Should not hit the network.
- encoding-rs. I believe this is built by default and preffed on, but I am unsure. Should not hit the network.
- rust-url for parsing, serialization, and manipulation of URLs. built by default, preffed off. This is a currently-stalled experiment which won't be enabled before we make it work well with everything. While this itself shouldn't be hitting the network (it's only for dealing with the URL data, not making requests), it will be audited more rigorously before being enabled (right now it's just there for experimentation)
- We unconditionally use rust-url's IPV6 parsing code as of https://bugzilla.mozilla.org/show_bug.cgi?id=1324243 . This code shouldn't hit the network.
The call to
getaddrinfomentioned here exists because there is aToSocketAddrsimplementation for URL; an implementation which is never invoked.However, we can probably add a build time option to remove them.
All the Rust code in Firefox gets built into
$objdir/toolkit/library/$target/(debug or release)/libgkrust.a, so inspecting that binary may be useful in ensuring that getaddrinfo is never called. Currently none of the Rust code being used should be calling it. However, the standard library does include a call to getaddrinfo that goes unused, which still turns up in that file -- I'm not sure how to differentiate between used and unused here -- I tried creating a test Rust staticlib that didn't do anything and even with-Cltothe final staticlib still had an unlinked getaddrinfo symbol. If y'all know the correct linker args andnm/objdumpinvocation to use, let me know and I'll run it on my local all-rust-enabled Firefox build.Let me know if you need more info!
Trac:
Username: manish.earth
