February 2018 - tbb-dev - lists.torproject.org

Next meeting: Tue, 20 Feb, 19:00 UTC in #tor-meeting
by Georg Koppen 05 Feb '18

05 Feb '18

Hi! We need to reschedule the next Tor Browser meeting. We found a new time just for that meeting that fits pretty well for everyone: On Tuesday, 20 Feb, 19:00 UTC in #tor-meeting as usual. See you there, Georg

1 0

Fwd: Intent to implement and ship navigator.webdriver
by Tom Ritter 05 Feb '18

05 Feb '18

Doesn't look like an issue, it will just expose a new flag which would provide version detection. ---------- Forwarded message ---------- From: Andreas Tolfsen <ato(a)sny.no> Date: Mon, Feb 5, 2018 at 10:37 AM Subject: Intent to implement and ship navigator.webdriver To: dev-platform <dev-platform(a)lists.mozilla.org> Cc: tools-marionette(a)lists.mozilla.org Summary: I intend to implement and ship a new enumerable, non-configurable, read-only "webdriver" attribute on the Navigator object. The attribute is true when the -marionette flag is passed to Firefox or the marionette.enabled preference is true. Otherwise it is false. Motivation: To give web authors a way to infer if user agent is controlled by automation, so the document can take alternate code paths when under test. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1169290 Standard: https://w3c.github.io/webdriver/webdriver-spec.html#interface Estimated target release: 60 Testing: Covered by WPT. Do other engines have this? Blink [1], Edge, and WebKit [2] have this. Blink only exposes the attribute during automation, but we expect them to unconditionally expose it given a recent specification change [3]. [1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/6GysDZCWwB8/rXbGoR… [2] https://git.webkit.org/?p=WebKit.git;a=commit;h=ce5ef8d5e72fb49cf2a0b72e2a5… [3] https://github.com/w3c/webdriver/commit/a224627dcea6448367523bf0420de3d5479… _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

1 0

Tor Browser uplift tracker
by Arthur D. Edelstein 05 Feb '18

05 Feb '18

Hi Tor Browser devs, I've been working on uplift this week and I have updated the uplift tracker table at https://torpat.ch . There are bugzilla bugs for most of our eligible patches, but there are still about 15 "untriaged" patches in gray, because I couldn't be sure if they were appropriate to uplift. If you have time to have a look at the untriaged ones you are familiar with and let me know if you think any are available for uplift, I would be grateful. My goal is to mark all patches either red, yellow, or green so that no untriaged patches remain. Thanks, Arthur

4 8

TASK03: more detailed analysis for ' --enable-rust ' on x86-android target
by WU RUXU 05 Feb '18

05 Feb '18

Hi all I have debug --enable-rust in tor-0.3.2.9 on x86-android target, with compare with arm-android target, find more details about this issue. debug output on x86-android in ffi.rs: Feb 05 02:01:00.161 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning RustString self 0xbf8ec7f8 RUST: rust_welcome_string Tor is running with Rust integration. Please report any bugs you encouter. 0xbf8ec7f8 C: &rust_str = 0xbf8ec870, rust_str = 0xa889a880 //printf(" C: &rust_str = %p, rust_str = %p\n", &rust_str, rust_str); Segmentation fault // when I try to print str:RustString address in rust_str_get, as following pub unsafe extern "C" fn rust_str_get(str: RustString) -> *const c_char { println!(" RUST: rust_str_get &str = {:p} ", &str); debug output on arm-android in ffi.rs: Feb 05 10:12:01.092 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning RustString self 0xbe810814 RUST: rust_welcome_string Tor is running with Rust integration. Please report any bugs you encouter. 0xbe810814 C: &rust_str = 0xbe810890, rust_str = 0xb66eb000 RUST: rust_str_get &str = 0xbe810810 //println!(" RUST: rust_str_get &str = {:p} ", &str); //? I don't known why the address is different with the address return in rust_welcome_string // but two address is very close // in C code, the address of rust_str is also very close to the address in RUST, it make sense. RustString self 0xbe810810 RUST: rust_str_get str = Tor is running with Rust integration. Please report any bugs you encouter. Feb 05 10:12:01.093 [notice] Tor is running with Rust integration. Please report any bugs you encouter. Compare the two debug output, rust_str return from rust_welcome_string is correct on two target. but in rust_str_get, rust_str passed from C code is invalid on x86-android target. the RUST code runing very well on x86-android target, only have issue work with C code -- Thanks PGP Fingerprint: F7BA D6CE 6592 77C7 0D2E 3BD5 5479 A15E B305 B8FE

1 0

TASK03 update
by WU RUXU 04 Feb '18

04 Feb '18

Hi all I have fork tor-android repo from n8fr8, merge previous changes, and some minor update in gralde & Java code. that should be easy to review all changes, and push commit here. https://github.com/wuruxu/tor-android/commit/7dfb581fb106f6d98b803c90c264c8… -- Thanks PGP Fingerprint: F7BA D6CE 6592 77C7 0D2E 3BD5 5479 A15E B305 B8FE

1 0

TASK03 on x86-android target
by WU RUXU 03 Feb '18

03 Feb '18

Hi all I have test tor x86 android binary on x86 android device, it cann't work with --enable-rust , rust_welcome_string & rust_str_get called by C code correctly, but in C code, rust_str_get always return zero length string, it's very strange. after read https://github.com/rust-lang/libc#platforms-and-documentation, I found that arm-linux-androideabi is the only one supported target on android platform. it may be the root cause of the issue on x86-android platform. -- Thanks PGP Fingerprint: F7BA D6CE 6592 77C7 0D2E 3BD5 5479 A15E B305 B8FE

1 0

bug fixed in TASK03
by WU RUXU 03 Feb '18

03 Feb '18

Hi all Today I found a mistake in external/tor-rust-patch-1 after I reboot computer , yesterday I had export env CARGO_TARGET_DIR in bash when I trace cargo build process manually. user@debian:~/dev/tor/tor-android$ git diff external/tor-rust-patch-1 diff --git a/external/tor-rust-patch-1 b/external/tor-rust-patch-1 index 26cda2f6..cf34a4c4 100644 --- a/external/tor-rust-patch-1 +++ b/external/tor-rust-patch-1 @@ -8,7 +8,7 @@ index ec3898577..36313fc60 100644 CARGO_HOME="$(abs_top_builddir)/src/rust" \ - $(CARGO) build --release --quiet $(CARGO_ONLINE) ) + $(CARGO) build --release --target $(TOR_CARGO_TARGET) --verbose $(CARGO_ONLINE); \ -+ cd $(CARGO_TARGET_DIR); \ ++ cd "$(abs_top_builddir)/src/rust/target"; \ + mkdir -p release; \ + cp $(TOR_CARGO_TARGET)/release/@TOR_RUST_UTIL_STATIC_NAME@ release;) -- Thanks PGP Fingerprint: F7BA D6CE 6592 77C7 0D2E 3BD5 5479 A15E B305 B8FE

1 0

Tor Browser TorLauncher Proposal
by Matthew Finkel 02 Feb '18

02 Feb '18

Hi All, Apologies for the delay in sending this. Attached (or below) is the proposal for migrating the TorLauncher legacy extension to WebExtension. The main problem with directly moving TorLauncher to using WebExtensions is the two Extensions APIs are not 1-to-1. There was significant functionality previously available that is not available with WebExtensions. In particular these involve launching a child process and controlling it. This is a primary objective of TorLauncher, so we needed an alternative. As a result, this proposal takes a mixed approach. Part of the functionality of TorLauncher will remain as an extension and the remaining functionality will be directly implemented into Tor Browser. >From the mobile/Android perspective, TorLauncher is a strange requirement at this moment. On Android, Orbot controls and configures tor, and external Apps cannot configure tor which is the purpose of TorLauncher. In the future, we may prefer another design and integration, providing a better user experience. Although the proposal is long, it is mostly documenting the extension's existing functionality. Thanks, Matt

4 5