Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-07-31T12:47:30Zhttps://gitlab.torproject.org/legacy/trac/-/issues/9476Completely drop support for Tor 0.2.2.x2020-07-31T12:47:30ZNick MathewsonCompletely drop support for Tor 0.2.2.xWe should remove 0.2.2.x from the recommended version list.
We should stop accepting Tor 0.2.2.x nodes in the network: that release series is completely unsupported.
Finally dropping 0.2.2.x will let us start deprecating things that we...We should remove 0.2.2.x from the recommended version list.
We should stop accepting Tor 0.2.2.x nodes in the network: that release series is completely unsupported.
Finally dropping 0.2.2.x will let us start deprecating things that we'd like to throw away, like the renegotiation-based handshake.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21449Make tor version parsing and version spec consistent2020-07-31T12:44:13ZteorMake tor version parsing and version spec consistentIn tor_version_compare, the git logic is a bit weird, because git tags are hashes: the ordering we apply isn't their true order. So the function comment should probably become:
```
/** Compare two tor versions; Return <0 if a < b; 0 if ...In tor_version_compare, the git logic is a bit weird, because git tags are hashes: the ordering we apply isn't their true order. So the function comment should probably become:
```
/** Compare two tor versions; Return <0 if a < b; 0 if a ==b, >0 if a >
* b. Git tags are sorted by length, then value. */
```
But this doesn't match version-spec.txt:
```
The EXTRA_INFO is also purely informational, often containing information
about the SCM commit this version came from. It is surrounded by parentheses
and can't contain whitespace. Unlike the STATUS_TAG this never impacts the way
that versions should be compared.
```
We should try to ignore the git tag, or at least be very careful how we compare it. Due to bugs like #20492, the following versions are equivalent:
```
Tor 0.2.9.9 (git-56788a2489127072)
Tor 0.2.9.9
```
(But these are not equivalent to any other git tag on Tor 0.2.9.9, which should never happen anyway.)
This is important when we try to exclude versions, like in #20509, because we need to exclude the version with and without the git tag.
This fix might require a new consensus method.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20509Directory authorities should reject relays with #20499 bug2020-07-31T12:44:02ZRoger DingledineDirectory authorities should reject relays with #20499 bugOnce we resolve #20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap fro...Once we resolve #20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap from e.g. sofia, which is a huge guard running 0.2.9.3-alpha.
Then later -- or maybe this will turn out to be the easiest solution for everything -- we can teach the directory authorities to simply reject descriptors from relays running these buggy versions.
[I'm not sure which milestone to put this in, since it will need to get into a majority of directory authorities for it to matter. :/ ]Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20492Tor git version is not generated in git worktrees2020-07-31T12:44:02ZteorTor git version is not generated in git worktreesWhen I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of ...When I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of compiler and architecture:
gcc (MacPorts gcc49 4.9.4_0+universal) 4.9.4 (i386/x86_64)
clang version 3.9.0 (tags/RELEASE_390/final) (x86_64)
$ git --version
git version 2.10.1
But when I compile it on Linux, I see a git commit hash:
```
Oct 28 14:28:15.669 [notice] Tor 0.3.0.0-alpha-dev (git-f3e158edf7d8128d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
```
Compiler:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ git --version
git version 2.6.3.36.g9a8c740
I'm putting this in 0.3.0 because it makes diagnosing issues much easier if we have the full commit. But feel free to disagree.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14881incorrect defaults when producing bandwidth-weights line in directory footer2020-07-31T12:42:39ZRob Jansenincorrect defaults when producing bandwidth-weights line in directory footerWhen running Tor in small testing networks, much of the time the bandwidth-weights line does not appear in the directory-footer in the consensus files. The log file shows messages like this:
```
Consensus with empty bandwidth: G=852123 ...When running Tor in small testing networks, much of the time the bandwidth-weights line does not appear in the directory-footer in the consensus files. The log file shows messages like this:
```
Consensus with empty bandwidth: G=852123 M=0 E=0 D=569253 T=1421376
```
The code that counts up these bandwidth values is in `networkstatus_compute_consensus` in `dirvote.c`, specifically around [line 1590 in Tor master as of now](https://gitweb.torproject.org/tor.git/tree/src/or/dirvote.c#n1590).
The code that prints this error is in `networkstatus_compute_bw_weights_v10` in `dirvote.c`.
I believe that it is an error not to produce bandwidth-weights in the event that we have no knowledge of bandwidth for a given position. For example, if D is zero because there are no nodes that serve as exits+guards, shouldn't we just adjust the weights accordingly? We may still have functional guards and functional exits just because we have no node that serves as both.
Since this is for weighting purposes, why are T, D, E, G, and M all initialized to 0 instead of 1? I think the default weight should be 1, meaning all positions are selected equally, and any bandwidth above 1 should be used to increase the weight. Does this sound right?
If that is not desired, then I request that we at least initialize these values to one for testing networks. One patch is attached for each of these options.Tor: 0.3.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/20284consensus weight case 2b3 does not follow dir-spec2020-07-31T12:42:39Zpastlyconsensus weight case 2b3 does not follow dir-spec[dir-spec](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2681) says the following.
```
If M > T/3, then the Wmd weight above will become negative. Set it to 0
in this case:
Wmd = 0
Wgd = weight_scale - Wed
```
The ...[dir-spec](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2681) says the following.
```
If M > T/3, then the Wmd weight above will become negative. Set it to 0
in this case:
Wmd = 0
Wgd = weight_scale - Wed
```
The code dutifully sets `Wmd` to 0, but neglects `Wgd`.
I assume the spec is correct and the intended behavior. Branch incoming once I get a ticket number.Tor: unspecifiedpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/28203Make chutney log the bootstrap progress for each node2020-07-28T23:20:05ZteorMake chutney log the bootstrap progress for each nodeTo solve #20473 and implement #22132, we need to know when nodes have bootstrapped.
Bootstrap progress is also useful when debugging failures.To solve #20473 and implement #22132, we need to know when nodes have bootstrapped.
Bootstrap progress is also useful when debugging failures.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/34443Audit Lottie?2020-07-19T04:50:58ZMatthew FinkelAudit Lottie?https://github.com/airbnb/lottie-androidhttps://github.com/airbnb/lottie-androidhttps://gitlab.torproject.org/legacy/trac/-/issues/34442Audit Flexbox?2020-07-19T04:50:58ZMatthew FinkelAudit Flexbox?https://github.com/google/flexbox-layout/tree/2.0.1
`com.google.android.flexbox.FlexboxLayoutManager`https://github.com/google/flexbox-layout/tree/2.0.1
`com.google.android.flexbox.FlexboxLayoutManager`https://gitlab.torproject.org/legacy/trac/-/issues/34441Audit Material Components library?2020-07-19T04:50:58ZMatthew FinkelAudit Material Components library?https://github.com/material-components/material-components-android/tree/1.1.0
`com.google.android.material.snackbar.Snackbar`
`com.google.android.material.appbar.AppBarLayout`https://github.com/material-components/material-components-android/tree/1.1.0
`com.google.android.material.snackbar.Snackbar`
`com.google.android.material.appbar.AppBarLayout`https://gitlab.torproject.org/legacy/trac/-/issues/34440Audit AndroidX libraries?2020-07-19T04:50:58ZMatthew FinkelAudit AndroidX libraries?#33939
> {{{
> > # More AndroidX com...#33939
> {{{
> > # More AndroidX compatibility libraries
> > androidx_legacy -> androidx.legacy:legacy-support-v4
> > androidx_paging -> androidx.paging:paging-runtime-ktx
> > androidx_preference -> androidx.preference:preference-ktx
> > androidx_fragment -> androidx.fragment:fragment-ktx
> > androidx_navigation_fragment -> androidx.navigation:navigation-fragment-ktx
> > androidx_navigation_ui -> androidx.navigation:navigation-ui
> > androidx_recyclerview -> androidx.recyclerview:recyclerview
> > androidx_lifecycle_livedata -> androidx.lifecycle:lifecycle-livedata-ktx
> > androidx_lifecycle_runtime -> androidx.lifecycle:lifecycle-runtime-ktx
> > androidx_lifecycle_viewmodel -> androidx.lifecycle:lifecycle-viewmodel-ktx
> > androidx_core -> androidx.core:core
> > androidx_core_ktx -> androidx.core:core-ktx
> > androidx_transition -> androidx.transition:transition
> > androidx_work_ktx -> androidx.work:work-runtime-ktx
> }}}https://gitlab.torproject.org/legacy/trac/-/issues/34439Isolate Icon loader on Android2020-07-19T04:50:58ZMatthew FinkelIsolate Icon loader on Androidhttps://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/browser/icons/src/main/java/mozilla/components/browser/icons/BrowserIcons.kt#L89
And what's `DataUriIconLoader`?
Coming from https://github.com/mozilla-mobile...https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/browser/icons/src/main/java/mozilla/components/browser/icons/BrowserIcons.kt#L89
And what's `DataUriIconLoader`?
Coming from https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/webnotifications/src/main/java/mozilla/components/feature/webnotifications/NativeNotificationBridge.kt#L68https://gitlab.torproject.org/legacy/trac/-/issues/34438Make sure TabCollections don't write in PBM on Android2020-07-19T04:50:58ZMatthew FinkelMake sure TabCollections don't write in PBM on Androidhttps://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/tab-collections/src/main/java/mozilla/components/feature/tab/collections/TabCollectionStorage.kt#L70https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/tab-collections/src/main/java/mozilla/components/feature/tab/collections/TabCollectionStorage.kt#L70https://gitlab.torproject.org/legacy/trac/-/issues/33661[S58] O2.4: Migrate Tor Browser for Android from ESR68 to Fenix.2020-07-19T04:47:39ZPili Guerra[S58] O2.4: Migrate Tor Browser for Android from ESR68 to Fenix.- Audit Fenix code for tracking, fingerprintability, and Tor safety features in relation to various known attacks.
- Audit code changes since last audit for proxy bypass bugs, following our audit procedure.
- Review all Mozilla devel...- Audit Fenix code for tracking, fingerprintability, and Tor safety features in relation to various known attacks.
- Audit code changes since last audit for proxy bypass bugs, following our audit procedure.
- Review all Mozilla developer documentation since the last audit for major changes that could impact our tracking and fingerprinting defenses.
- Review all closed bugs in Mozilla's bug tracker to find changes not mentioned in the developer documentation that still affect our users and their threat model.
- Update the Tor Browser for Android codebase to use Fenix instead of Fennec.
- Implement new UI changes as determined in O2.2.
- Integrate tor into Fenix.
- Integrate necessary webextensions into Fenix.
- Rewrite patches from Fennec into Fenix.
- Implement and test migration logic to allow users to seamlessly upgrade from Tor Browser for Android based on Gecko to Tor Browser for Android based on Fenix.
- Release a new version of Tor Browser for Android based on Fenix.
- Document and report in a retrospective on the success of our migration process from Fennec to Fenixhttps://gitlab.torproject.org/legacy/trac/-/issues/21657Test to make sure we isolate or disable all speculative connects2020-07-19T04:47:39ZArthur EdelsteinTest to make sure we isolate or disable all speculative connectsThere are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
```
link rel=preconnect
link rel=prefetch
link rel=prerender
```
and possibly more.
We ...There are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
```
link rel=preconnect
link rel=prefetch
link rel=prerender
```
and possibly more.
We should test this for the ESR45 and ESR52 versions of Tor Browser, because isolation will have different mechanisms.
See https://w3c.github.io/resource-hints/
We should also look into "SpeculativeConnect" code in Firefox to make sure there aren't any other cases of non-first-party isolated connections.https://gitlab.torproject.org/legacy/trac/-/issues/34429Check the DigitalAssetLinksHandler's use of the Fetch client is FPI2020-07-19T04:47:39ZMatthew FinkelCheck the DigitalAssetLinksHandler's use of the Fetch client is FPIhttps://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/customtabs/src/main/java/mozilla/components/feature/customtabs/verify/DigitalAssetLinksHandler.kt#L50https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/customtabs/src/main/java/mozilla/components/feature/customtabs/verify/DigitalAssetLinksHandler.kt#L50https://gitlab.torproject.org/legacy/trac/-/issues/34428Handle CustomTabs safely on Android2020-07-19T04:47:39ZMatthew FinkelHandle CustomTabs safely on AndroidMake sure this is safe in Fenix
https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/customtabs/src/main/java/mozilla/components/feature/customtabs/CustomTabWindowFeature.kt#L86
And PendingIntent
https:/...Make sure this is safe in Fenix
https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/customtabs/src/main/java/mozilla/components/feature/customtabs/CustomTabWindowFeature.kt#L86
And PendingIntent
https://github.com/mozilla-mobile/android-components/blob/v44.0.1/components/feature/customtabs/src/main/java/mozilla/components/feature/customtabs/CustomTabsToolbarFeature.kt#L260https://gitlab.torproject.org/legacy/trac/-/issues/34427Make sure SessionStorage is not used in PBM on Android2020-07-19T04:47:38ZMatthew FinkelMake sure SessionStorage is not used in PBM on AndroidIn Android-Components:
`components/browser/session/src/main/java/mozilla/components/browser/session/storage/SessionStorage.kt`
Make sure Fenix doesn't use it in PBM.In Android-Components:
`components/browser/session/src/main/java/mozilla/components/browser/session/storage/SessionStorage.kt`
Make sure Fenix doesn't use it in PBM.https://gitlab.torproject.org/legacy/trac/-/issues/34177Audit Fenix code for tracking, fingerprintability, and safety features2020-07-19T04:47:38ZMatthew FinkelAudit Fenix code for tracking, fingerprintability, and safety featuresAudit Fenix code for tracking, fingerprintability, and Tor safety features in relation to various known attacks.
- Audit code changes since last audit for proxy bypass bugs, following our audit procedure.Audit Fenix code for tracking, fingerprintability, and Tor safety features in relation to various known attacks.
- Audit code changes since last audit for proxy bypass bugs, following our audit procedure.https://gitlab.torproject.org/legacy/trac/-/issues/34342Audit androidx_biometric2020-07-19T04:41:03ZMatthew FinkelAudit androidx_biometric> androidx_biometric -> androidx.biometric:biometric
https://developer.android.com/jetpack/androidx/releases/biometric
https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-biometric-release/biometric/> androidx_biometric -> androidx.biometric:biometric
https://developer.android.com/jetpack/androidx/releases/biometric
https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-biometric-release/biometric/