Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:26:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34451Include Tor Browser Manual in packages during build2020-06-16T01:26:35ZMatthew FinkelInclude Tor Browser Manual in packages during buildhttps://gitlab.torproject.org/legacy/trac/-/issues/34450Warn about proxy-bypass when opening external apps on Android2020-06-15T23:01:33ZMatthew FinkelWarn about proxy-bypass when opening external apps on AndroidFollow up from #26529 for FenixFollow up from #26529 for Fenixhttps://gitlab.torproject.org/legacy/trac/-/issues/34449There are too many networks in the chutney networks directory.2020-06-13T13:31:53ZNick MathewsonThere are too many networks in the chutney networks directory.There are 66 "networks" files in the chutney networks directory; of these, I doubt more than a few are actually used for testing things nowadays. I believe we should move aside (or just remove) the ones that are not in current use.
Thi...There are 66 "networks" files in the chutney networks directory; of these, I doubt more than a few are actually used for testing things nowadays. I believe we should move aside (or just remove) the ones that are not in current use.
This came up for me because I will need to make a change to some networks in #34447, and for now it is very hard to tell which of these 66 files I need to make a change for.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34448Chutney templates may need an option-fallback feature2020-06-13T13:31:53ZNick MathewsonChutney templates may need an option-fallback featureIn the parent, we want to split AssumeReachable into AssumeSelfReachable and AssumeOthersReachable. We will want Chutney authorities to set AssumeSelfReachable if that option exists, but AssumeReachable if it does not.
That's not somet...In the parent, we want to split AssumeReachable into AssumeSelfReachable and AssumeOthersReachable. We will want Chutney authorities to set AssumeSelfReachable if that option exists, but AssumeReachable if it does not.
That's not something that the chutney config system can do right now AFAICT.
It might be simpler to do this with a magic bit of code specific to assumereachable as part of the chutney system, but I'm not sure.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34447Chutney networks need at least 3 AssumeReachable nodes.2020-06-13T13:31:52ZNick MathewsonChutney networks need at least 3 AssumeReachable nodes.Unless at least three nodes on a chutney network are AssumeReachable, the consensus as published will not have 3 descriptors in it. Without 3 descriptors in the initial consensus, relays won't be able to build self-testing circuits, dec...Unless at least three nodes on a chutney network are AssumeReachable, the consensus as published will not have 3 descriptors in it. Without 3 descriptors in the initial consensus, relays won't be able to build self-testing circuits, decide they are reachable, and publish their own descriptors... so they will never join the consensus.
Right now, this problem is masked by #34446, which means that we haven't actually disabled AssumeReachable as much as we think we have.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34446TestingTorNetwork should not set AssumeReachable 12020-06-13T15:53:49ZNick MathewsonTestingTorNetwork should not set AssumeReachable 1For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable...For S55 we are trying to get self-tests and remote-tests working with IPv6. To make sure we've succeed, we need to try them with Chutney. But to try them with chutney, we need them to be enabled.
With #33583 we removed AssumeReachable from the chutney configurations. But that didn't actually have any effect, since `AssumeReachable 1` is implicit in `TestingTorNetwork 1`.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34445Split assumereachable into self and authority components2020-06-13T15:53:48ZNick MathewsonSplit assumereachable into self and authority componentsThis option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.This option governs both "should I check if I, a relay, reachable" and "should I, an authority, check if relays are reachable"? These should really be separated.
Calling this S55-must since we need it for chutney-ipv6 stuff.Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34444Update relay_recent_measurement_attempt_count and relay_recent_priority_list_...2020-06-13T16:16:43ZjugaUpdate relay_recent_measurement_attempt_count and relay_recent_priority_list_count are correctlyAs commented in https://trac.torproject.org/projects/tor/ticket/34309#comment:2As commented in https://trac.torproject.org/projects/tor/ticket/34309#comment:2sbws: 1.2.x-finalhttps://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/34437migrate help.tpo into a gitlab wiki2020-06-13T17:02:28Zanarcatmigrate help.tpo into a gitlab wikiwe are currently using ikiwiki to host our documentation. that has served us well so far: it's available as a static site in the static mirror system and allows all sysadmins to have a static, offsite copy of the documentation when every...we are currently using ikiwiki to host our documentation. that has served us well so far: it's available as a static site in the static mirror system and allows all sysadmins to have a static, offsite copy of the documentation when everything is down.
but ikiwiki is showing its age. it's an old program written in Perl, difficult to theme and not very welcoming to new users. for example, it's impossible for a user unfamiliar with git to contribute to the documentation. it also has its own unique Markdown dialect that is not used anywhere else. and while Markdown itself is not standardized and has lots of such dialects, there is /some/ convergence around CommonMark and GFM (GitHub's markdown) as de-facto standards at least, which ikiwiki still has to catchup with. it also has powerful macros which are nice to make complex websites, but do not render in the offline documentation, making us dependent on the rendered copy (as opposed to setting up client-side tools to peruse the documentation).
gitlab wikis, in contrast, have a web interface to edit pages. it doesn't have the macros ikiwiki has, but that's nothing a few commandline hacks can't fix... or at least we should consider it. they don't have macros or any more powerful features that ikiwiki has, but maybe that's exactly what we want.
this is not blocking the trac to gitlab migration, but it would be nice to jump onboard with everyone, since we will be migrating the Trac wiki onto gitlab as well...anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34436document the static mirror network and onionbalance system better2020-06-13T17:02:28Zanarcatdocument the static mirror network and onionbalance system betterwe have some documentation on the static mirroring system here:
https://help.torproject.org/tsa/howto/static-component/
it's mostly procedural and minimal: add a component, remove a component and that's it. it doesn't explain at all ho...we have some documentation on the static mirroring system here:
https://help.torproject.org/tsa/howto/static-component/
it's mostly procedural and minimal: add a component, remove a component and that's it. it doesn't explain at all how the system works, how to create or remove a new node in the network, how onion services interact with it, and how it actually works in puppet.
all this should be better documented. for example, I should be able to resolve #34396 without asking weasel. :)anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/34435Update bug-reporting links for gitlab2020-06-13T18:22:19ZDavid Fifielddcf@torproject.orgUpdate bug-reporting links for gitlabAfter the [gitlab migration](https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html) we need to update bug-reporting instructions.
* https://snowflake.torproject.org/#bugs\\
https://gitweb.torproject.org/pluggable-...After the [gitlab migration](https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html) we need to update bug-reporting instructions.
* https://snowflake.torproject.org/#bugs\\
https://gitweb.torproject.org/pluggable-transports/snowflake-webext.git/tree/static/index.html?h=webext-0.3.1&id=d2a9a8fd136ac6bbba393de3d51fb7ca85e17b8a#n75
I checked in snowflake.git and did not find anything that needs to be changed.https://gitlab.torproject.org/legacy/trac/-/issues/34434Remove unused $var: 1 declarations in rbm.conf2020-06-16T01:26:35ZGeorg KoppenRemove unused $var: 1 declarations in rbm.confThere are a bunch of unused $var: 1 declarations in `rbm.conf` (that is they don't have a matching `[% c("var/$var") %]` check). We should clean that up and keep things tidy so that it is obvious where things need to get added and where ...There are a bunch of unused $var: 1 declarations in `rbm.conf` (that is they don't have a matching `[% c("var/$var") %]` check). We should clean that up and keep things tidy so that it is obvious where things need to get added and where they are not needed.https://gitlab.torproject.org/legacy/trac/-/issues/34433Replace clang-format.sh with a faster, better version2020-06-13T15:53:47ZNick MathewsonReplace clang-format.sh with a faster, better versionWe need to replace clang-format.sh with a version that meets our use-cases.
Notably:
* we need to be able to check whether anything is misformatted without actually reformatting it.
* we need to be able to look at only those files th...We need to replace clang-format.sh with a version that meets our use-cases.
Notably:
* we need to be able to check whether anything is misformatted without actually reformatting it.
* we need to be able to look at only those files that are staged to be committed, so that our git hooks can work.
* we need a mode to reformat everything that has changed in git, so that we can run a quick "reformat everything" command without scanning the entire repostiory (which takes around 60 seconds for me).Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34432Integrate fenix toolchain into tor-browser-build's master2020-06-16T01:26:35ZGeorg KoppenIntegrate fenix toolchain into tor-browser-build's masterWe decided to not create a new branch to take care of the Fenix toolchain while continuing to build nightly builds with the ESR 68 toolchains (and later ESR 78 toolchains for desktop builds). Rather, we'll follow boklm's idea of namespac...We decided to not create a new branch to take care of the Fenix toolchain while continuing to build nightly builds with the ESR 68 toolchains (and later ESR 78 toolchains for desktop builds). Rather, we'll follow boklm's idea of namespacing the projects to fenix-$project if there are Fenix specific needs and keep everything on `master`. This should avoid diverging branches and a tricky merge at the end.Georg KoppenGeorg Koppen