The rust code in 52 might have been proxy unsafe, so Tor turned it off. We should make sure it is proxy safe. https://trac.torproject.org/projects/tor/ticket/21862
Somehow related: bug 1367932 comment 1.
The getaddrinfo call is from the ToSocketAddrs impl, which is a trait impl in the url crate not used by the Rust integration. As far as I can tell, none of the ongoing Rust projects should involve any getaddrinfo calls.
Is there any way we can reliably enforce that?
What do we do for C++ code right now? I suspect the correct linker script / link args would work. I tried compiling an empty Rust library with LTO (rustc test.rs -Clto --crate-type=staticlib), however the library still had an unlinked getaddrinfo symbol. There should be some combo of link args and nm/objdump/readelf calls that let us differentiate between a staticlib that uses a symbol and one that doesn't. I'm not sure what it is.
I don't believe we have anything for C++ code, because historically we haven't imported arbitrary C++ code that can do networking. :) I guess the best thing to do here would be to add stub functions for libc networking functions that we don't want Rust code calling directly, and have them proxy everything to Necko? It sounds like as-filed this bug is INVALID, because the way we're using the rust-url crate does not cause it to do DNS lookups with getaddrinfo, but we don't have any backstops that would actually prevent that, so maybe we can just morph this bug to cover that. glandium: does my vague proposal sound plausible?
Summary: Rust Code may not obey proxy safety → Enforce that Rust code is proxy-safe (doesn't call directly into libc networking functions)
I would rather have stub functions that just abort. We'd have to force Rust to link to those in such a way that the final XUL link step isn't polluted. I'm not sure how that can be done, perhaps a linker script?
I assume that if we linked in a Rust crate that provided the right symbols it might work, but we'd have to ensure that they did not wind up as public symbols to which the other stuff in XUL would work. I'm also not sure what extern linkage actually does in Rust, so it's possible this would not work.
We create a regular C-like staticlib; we could link those symbols in first and create a different staticlib, and then link it into XUL?
This bug is showing up in some Firefox 57 tracking dashboard because it was changed recently. I don't think it has anything to do with Firefox 57, so I'm setting the tracking flag so it doesn't show up. If anyone disagrees, please change the flag!
status-firefox57: --- → wontfix
Hey Georg, I'm flagging you in this to help us figure out what/how we should proceed.
Not sure what exactly I should help with but comments 5-8 had some ideas about how to solve this bug. I am not familiar enough with Rust/linking internals to evaluate that one but, yes, we are very interested in a solution that avoids us removing random network related Rust APIs just because we can't be sure that there is no way they can bypass the proxy settings in the browser.
2 months ago
Whiteboard: [tor] → [tor 21862]
2 months ago
You need to log in before you can comment on or make changes to this bug.