Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:39Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34251Fix edge case handling in Rust protover is supported2020-06-13T15:53:39ZteorFix edge case handling in Rust protover is supportedTor's Rust FFI for protocol_list_supports_protocol_or_later() returns true for the empty protocol list.
In C, the function returns false, but this behaviour is undocumented.
This bug doesn't affect protocol_list_supports_protocol() in ...Tor's Rust FFI for protocol_list_supports_protocol_or_later() returns true for the empty protocol list.
In C, the function returns false, but this behaviour is undocumented.
This bug doesn't affect protocol_list_supports_protocol() in Rust, because the Rust error checks are done in a different order.
I'll add a quick fix to #33222, but someone else will need to do the backport. We might want to do the Rust error checks in the same order, too.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34250Fix torbutton noscript-control race condition2020-06-16T01:13:07ZAlex CatarineuFix torbutton noscript-control race conditionWhile debugging some testsuite tests, I saw some race condition with the noscript initialization which prevents some tests from running correctly.
We currently listen for both `startup` and `pageshow` events [here](https://gitweb.torpro...While debugging some testsuite tests, I saw some race condition with the noscript initialization which prevents some tests from running correctly.
We currently listen for both `startup` and `pageshow` events [here](https://gitweb.torproject.org/torbutton.git/tree/modules/noscript-control.js?id=36f8182a25818548d62b7fbc6be4d2472773b820#n149), and in some tests, `pageshow` events are being received before `startup`, which results in the configuration message being lost and noscript being initialized with the default settings, blocking scripts.
This was originally introduced in #27427, which added checks for the event types precisely because of these issues. However, "pageshow" in specific situations also seems to trigger those.
In that ticket, "pageshow" was added `for a slightly more graceful failure mode in case Torbutton somehow misses NoScript startup`. However, I don't think that can really happen, and I suggest we just listen to `startup`.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/34249Make sure the C and Rust protovers can't get out of sync2020-06-13T15:53:38ZteorMake sure the C and Rust protovers can't get out of syncThere is a recurring bug, where we modify the C protover, but forget the Rust protover. (See #34248, #33285, #29631 for similar issues.)
We could fix the underlying issue by fetching the string from a common location, using C's `#includ...There is a recurring bug, where we modify the C protover, but forget the Rust protover. (See #34248, #33285, #29631 for similar issues.)
We could fix the underlying issue by fetching the string from a common location, using C's `#include` or Rust's `include_str!()`.
Then we could test that C and Rust are the same by putting a copy of the protover string in the unit tests, and making sure that it matches the currently supported protocol versions.
This fix and test will be important for proposal 318, because it will modify both protocol version implementations:
https://github.com/torproject/torspec/blob/master/proposals/318-limit-protovers.mdTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34248Declare HSIntro=5 in Tor's rust protover implementation2020-06-13T15:53:38ZteorDeclare HSIntro=5 in Tor's rust protover implementationMy protover tests for #33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in #33222, but I want to leave the backport to David.My protover tests for #33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in #33222, but I want to leave the backport to David.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34247Update tor-browser-build README2020-06-16T01:13:07ZGeorg KoppenUpdate tor-browser-build READMEOver the time some errors and things to correct have accumulated in the `README` file. We should fix them.Over the time some errors and things to correct have accumulated in the `README` file. We should fix them.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/34246Add a link to the formatted architecture docs in src/mainpage.md2020-06-13T15:53:37ZteorAdd a link to the formatted architecture docs in src/mainpage.mdWhen I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?When I open up src/mainpage.md. it's obviously meant to be formatted by a markdown parser. (And GitHub's markdown doesn't seem to handle "@" directives.)
Can you add a link to the formatted output at the top of mainpage.md ?Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2020-06-13T15:53:37ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34244Fallback details changed for 1938EBACBB1A7BFA888D9623C90061130E63BB3F2020-06-13T16:06:53ZAlexander Færøyahf@torproject.orgFallback details changed for 1938EBACBB1A7BFA888D9623C90061130E63BB3FFrom tor-relays@lists.torproject.org:
```
Date: Sun, 17 May 2020 07:53:52 +0000
From: Anders Burmeister <...>
To: "tor-relays@lists.torproject.org" <tor-relays@lists.torproject.org>
Subject: [tor-relays] EOL 1938EBACBB1A7BFA888D9623C900...From tor-relays@lists.torproject.org:
```
Date: Sun, 17 May 2020 07:53:52 +0000
From: Anders Burmeister <...>
To: "tor-relays@lists.torproject.org" <tor-relays@lists.torproject.org>
Subject: [tor-relays] EOL 1938EBACBB1A7BFA888D9623C90061130E63BB3F FallbackDir
FallbackDir
1938EBACBB1A7BFA888D9623C90061130E63BB3F
Expired
rest of the family happily up and running.
/anders
```
The relay is still running though.https://gitlab.torproject.org/legacy/trac/-/issues/34243debootstrap-image project for Linux fails with segfault2020-06-16T01:13:06ZGeorg Koppendebootstrap-image project for Linux fails with segfaultOn one of my machines creating a Linux container fails:
```
W: Failure trying to run: chroot "/var/tmp/tmp.HiqNC7Q599/base-image" dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /var/tmp/tmp.Hiq...On one of my machines creating a Linux container fails:
```
W: Failure trying to run: chroot "/var/tmp/tmp.HiqNC7Q599/base-image" dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb
W: See /var/tmp/tmp.HiqNC7Q599/base-image/debootstrap/debootstrap.log for details
```
And that log says:
```
2020-05-17 19:15:26 URL:http://archive.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb [87392/87392] -> "/var/tmp/tmp.uv7kNeRkLc/base-image//var/cache/apt/archives/partial/zlib1g_1%3a1.2.7.dfsg-13_amd64.deb" [1]
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
missing architecture
Segmentation fault
```
I originally hit this when trying to solve #34242. To have a chance to repro one needs the fix for #34242, too.https://gitlab.torproject.org/legacy/trac/-/issues/34242Creating containers for Linux targets is busted due to outdated apt2020-06-16T01:13:06ZGeorg KoppenCreating containers for Linux targets is busted due to outdated aptFor Linux containers we hardcode `0.9.7.9+deb7u8` as the minimal `apt` version but that's not available anymore on `deb.freexian.com`. Rather it's `0.9.7.9+deb7u9` now.For Linux containers we hardcode `0.9.7.9+deb7u8` as the minimal `apt` version but that's not available anymore on `deb.freexian.com`. Rather it's `0.9.7.9+deb7u9` now.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/34241tba crash saving image2020-06-16T01:13:05Ztraumschuletba crash saving image- tba version: 68.8.0 (9.5a12)
- includes several Gecko traces for error code [0x80004005](https://helpful.knobs-dials.com/index.php/0x80004005_(NS_ERROR_FAILURE)_and_other_firefox_errors) (catch-all ff error) equal to #31572 and #33966
...- tba version: 68.8.0 (9.5a12)
- includes several Gecko traces for error code [0x80004005](https://helpful.knobs-dials.com/index.php/0x80004005_(NS_ERROR_FAILURE)_and_other_firefox_errors) (catch-all ff error) equal to #31572 and #33966
STR:
1) start and connect TBA (without this step the page won't be loaded after connecting)
2) in another application share a link with TBA
3) "Open in Tor Browser"
4) "Save Image As"
Result:
```
05-17 15:19:16.044 5623 5641 E AndroidRuntime: FATAL EXCEPTION: GeckoBackgroundThread
05-17 15:19:16.044 5623 5641 E AndroidRuntime: Process: org.torproject.torbrowser_alpha, PID: 5623
05-17 15:19:16.044 5623 5641 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.net.InetAddress.toString()' on a null object reference
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at com.android.okhttp.internal.Util.closeQuietly(Util.java:96)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at com.android.okhttp.internal.http.StreamAllocation.deallocate(StreamAllocation.java:293)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at com.android.okhttp.internal.http.StreamAllocation.streamFinished(StreamAllocation.java:234)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at com.android.okhttp.internal.http.Http1xStream$AbstractSource.endOfInput(Http1xStream.java:571)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at com.android.okhttp.internal.http.Http1xStream$FixedLengthSource.read(Http1xStream.java:610)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at com.android.okhttp.okio.RealBufferedSource$1.read(RealBufferedSource.java:396)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at java.io.InputStream.read(InputStream.java:101)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.downloadImageForSetImage(GeckoApplication.java:887)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.access$300(GeckoApplication.java:82)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication$6.run(GeckoApplication.java:847)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.permissions.PermissionBlock.executeRunnable(PermissionBlock.java:139)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.permissions.PermissionBlock.onPermissionsGranted(PermissionBlock.java:118)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.permissions.PermissionBlock.run(PermissionBlock.java:98)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.setImageAs(GeckoApplication.java:844)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.access$100(GeckoApplication.java:82)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication$EventListener.handleMessage(GeckoApplication.java:649)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.EventDispatcher$3.run(EventDispatcher.java:368)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:873)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:99)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at android.os.Looper.loop(Looper.java:216)
05-17 15:19:16.044 5623 5641 E AndroidRuntime: at org.mozilla.gecko.util.GeckoBackgroundThread.run(GeckoBackgroundThread.java:41)
```
Alternative way:
1) Open and connect TBA
2) Click "Donate Now"
3) Long tap the logo
4) Switch to the Image tab
5) "Set As"
6) See the `Unable to set image` message
7) "Set As" again
Result:
```
05-17 15:57:13.538 24022 24041 E AndroidRuntime: FATAL EXCEPTION: GeckoBackgroundThread
05-17 15:57:13.538 24022 24041 E AndroidRuntime: Process: org.torproject.torbrowser_alpha, PID: 24022
05-17 15:57:13.538 24022 24041 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.net.InetAddress.toString()' on a null object reference
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.Util.closeQuietly(Util.java:96)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.http.StreamAllocation.deallocate(StreamAllocation.java:293)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.http.StreamAllocation.connectionFailed(StreamAllocation.java:330)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.http.StreamAllocation.connectionFailed(StreamAllocation.java:325)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.http.StreamAllocation.recover(StreamAllocation.java:373)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.http.HttpEngine.recover(HttpEngine.java:479)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.http.HttpEngine.recover(HttpEngine.java:495)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:523)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:434)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:248)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getInputStream(DelegatingHttpsURLConnection.java:210)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:26)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.downloadImageForSetImage(GeckoApplication.java:882)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.access$300(GeckoApplication.java:82)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication$6.run(GeckoApplication.java:847)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.permissions.PermissionBlock.executeRunnable(PermissionBlock.java:139)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.permissions.PermissionBlock.onPermissionsGranted(PermissionBlock.java:118)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.permissions.PermissionBlock.run(PermissionBlock.java:98)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.setImageAs(GeckoApplication.java:844)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication.access$100(GeckoApplication.java:82)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.GeckoApplication$EventListener.handleMessage(GeckoApplication.java:649)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.EventDispatcher$3.run(EventDispatcher.java:368)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:873)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:99)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at android.os.Looper.loop(Looper.java:216)
05-17 15:57:13.538 24022 24041 E AndroidRuntime: at org.mozilla.gecko.util.GeckoBackgroundThread.run(GeckoBackgroundThread.java:41)
```
LMK if you are interested in the complete log.https://gitlab.torproject.org/legacy/trac/-/issues/34240Update Metrics CollecTor check to remove Torperf files2020-06-13T17:02:15ZKarsten LoesingUpdate Metrics CollecTor check to remove Torperf filesWe stopped archiving Torperf files in #34141, and now the check starts complaining about them not being recent anymore: `CRITICAL: Got a valid response from https://collector.torproject.org/index/index.json with at least one timestamp be...We stopped archiving Torperf files in #34141, and now the check starts complaining about them not being recent anymore: `CRITICAL: Got a valid response from https://collector.torproject.org/index/index.json with at least one timestamp being critically outdated: /recent/torperf/ = 2020-05-16 00:10 (33 = 30 + 3 hours ago)`
I'm attaching a patch.anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34239Release CollecTor 1.15.22020-06-13T17:52:32ZKarsten LoesingRelease CollecTor 1.15.2I need to put out CollecTor 1.15.2 today with an update to metrics-lib 2.13.0 in order to archive OnionPerf's analysis results file format version 2.0.I need to put out CollecTor 1.15.2 today with an update to metrics-lib 2.13.0 in order to archive OnionPerf's analysis results file format version 2.0.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34238Space out some function calls in parse_short_policy()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34237Fix spacing in if statement in tor_version_parse()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34236Fix spacing in if statement in port_parse_config()2020-06-13T15:53:35ZNeel Chauhanneel@neelc.orgFix spacing in if statement in port_parse_config()This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34235Release metrics-lib 2.13.02020-06-13T17:58:28ZKarsten LoesingRelease metrics-lib 2.13.0I'm putting out metrics-lib 2.13.0 today to parse OnionPerf's analysis results file format 2.0 (#34224).I'm putting out metrics-lib 2.13.0 today to parse OnionPerf's analysis results file format 2.0 (#34224).Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/34234Use Debian 10 for our https-everywhere container image2020-06-16T01:26:28ZboklmUse Debian 10 for our https-everywhere container imageWe are currently using Debian Stretch to build https-everywhere for any platform.
We can update that to Debian 10.
It looks like the https-everywhere build still requires python3.6 while Debian 10 provides version 3.7, so we still need...We are currently using Debian Stretch to build https-everywhere for any platform.
We can update that to Debian 10.
It looks like the https-everywhere build still requires python3.6 while Debian 10 provides version 3.7, so we still need our own build of python3.6. However the update to Debian 10 will allow us to share the python3.6 build with the osx64 and windows builds as they will be using Debian 10 too.https://gitlab.torproject.org/legacy/trac/-/issues/34233Fix use of == in configure.ac2020-06-13T15:53:35ZNick MathewsonFix use of == in configure.acA user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.A user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34232Make summarize_protover_flags() handle NULL and empty string the same2020-06-13T15:53:34ZteorMake summarize_protover_flags() handle NULL and empty string the samesummarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline t...summarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline that functions should treat NULL and "" in similar ways. (Or the difference should be clearly documented.)
So we should ignore "" protovers, the same way we ignore NULL protovers. (Relays with empty protovers won't end up in the consensus, and clients can't use them for anything. So this change should have no real impact.)Tor: unspecified