The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-23T19:32:59Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40019scw-arm-par-01 should be upgraded to buster(Debian 10) or retired2020-06-23T19:32:59Zweasel (Peter Palfrader)scw-arm-par-01 should be upgraded to buster(Debian 10) or retiredweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/27block /webhook/ on irc bot2020-06-23T20:27:06Zanarcatblock /webhook/ on irc botthe irc bot has /webhook/ wide open to the world right now, and without a password. block the /webhook/ route in nginx and restrict it to the gitlab host.the irc bot has /webhook/ wide open to the world right now, and without a password. block the /webhook/ route in nginx and restrict it to the gitlab host.anarcatanarcathttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40001Style consideration for shell script `set` directives2020-06-24T02:43:18ZcStyle consideration for shell script `set` directivesTicket #33604 wants shell scripts to be more pedantic. However, looking at current scripts, some use `set -e` and others use the longer verbose `set -o errexit`, so which do we want?
Furthermore there is also the option to set these in ...Ticket #33604 wants shell scripts to be more pedantic. However, looking at current scripts, some use `set -e` and others use the longer verbose `set -o errexit`, so which do we want?
Furthermore there is also the option to set these in the shebang line (i.e. `#!/bin/sh -eu`), which to me is nicer because it's clear that these flags apply to the script. When adding code we definitely don't want someone to place any lines of code above the `set -eu`, so having it in the shebang would prevent that.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40003Document DEFAULTS options in TorNet.py2020-06-24T14:07:37ZcDocument DEFAULTS options in TorNet.pyThere is a comment that states plainly `# XXX: document these options` so I will go ahead and make a tracking issue for this. I think some of these options are documented in other places in the code already, so that should make the job a...There is a comment that states plainly `# XXX: document these options` so I will go ahead and make a tracking issue for this. I think some of these options are documented in other places in the code already, so that should make the job a bit easier.cchttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40020Please refresh sysrqb's pgp key2020-06-24T14:52:17ZMatthew FinkelPlease refresh sysrqb's pgp key```
$ gpg2 -k CE1782624600EE98764C6D9CCB8FC772D1AA1D30
pub rsa4096/0xCB8FC772D1AA1D30 2014-06-26 [SC] [expires: 2020-12-20]
Key fingerprint = CE17 8262 4600 EE98 764C 6D9C CB8F C772 D1AA 1D30
uid [ unknown] Mat...```
$ gpg2 -k CE1782624600EE98764C6D9CCB8FC772D1AA1D30
pub rsa4096/0xCB8FC772D1AA1D30 2014-06-26 [SC] [expires: 2020-12-20]
Key fingerprint = CE17 8262 4600 EE98 764C 6D9C CB8F C772 D1AA 1D30
uid [ unknown] Matthew Finkel <sysrqb@torproject.org>
uid [ unknown] Matthew Finkel <Matthew.Finkel@gmail.com>
uid [ unknown] Matthew Finkel <sysrqb@protonmail.com>
uid [ unknown] Matthew Finkel <sysrqb@riseup.net>
sub rsa2048/0x0282E4E0C8F56C94 2020-06-23 [S] [expires: 2020-12-20]
sub rsa2048/0x44ADFA83E76BD9F5 2020-06-23 [E] [expires: 2020-12-20]
sub rsa2048/0xCA1E0E95A87E21A2 2020-06-23 [A] [expires: 2020-12-20]
```
[CE1782624600EE98764C6D9CCB8FC772D1AA1D30](/uploads/43e2879bc78397b19fb560f2b967e485/CE1782624600EE98764C6D9CCB8FC772D1AA1D30)
Thanks.anarcatanarcathttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40008Update sysrqb's PGP key in the torbutton keychain2020-06-24T15:41:44ZMatthew FinkelUpdate sysrqb's PGP key in the torbutton keychainSee tpo/tpa/services#40020 for details.See tpo/tpa/services#40020 for details.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40009Improve tor's client auth stability2020-06-24T20:03:43ZMatthew FinkelImprove tor's client auth stabilitytpo/core/tor#33458 was backported to 0.4.3, but it's not included in 0.4.3.5 (and I don't know when 0.4.3.6 will be tagged). The client auth UI is now available in Tor Browser 9.5, so let's cherry-pick the patch and include it in the bui...tpo/core/tor#33458 was backported to 0.4.3, but it's not included in 0.4.3.5 (and I don't know when 0.4.3.6 will be tagged). The client auth UI is now available in Tor Browser 9.5, so let's cherry-pick the patch and include it in the build until 0.4.3.6 is tagged.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40021rename "services" project to "team"2020-06-24T21:14:31Zanarcatrename "services" project to "team"as part of tpo/tpa/gitlab#28, we discussed the idea of having a "team" project for each team which would include the team's wiki and main issue tracker.
it seems to be what this project is.
so let's rename it to "team". gitlab will tak...as part of tpo/tpa/gitlab#28, we discussed the idea of having a "team" project for each team which would include the team's wiki and main issue tracker.
it seems to be what this project is.
so let's rename it to "team". gitlab will take care of doing the necessary redirections later on.anarcatanarcathttps://gitlab.torproject.org/tpo/community/support/-/issues/40002"support wiki" is going away2020-06-24T21:18:04Zanarcat"support wiki" is going awayHi!
I am not sure anyone here is aware of it, but there's a wiki for the community/support team!
https://help.torproject.org/support/
This was managed by Lunar and hasn't been updated in about 6 years, so I doubt anyone still uses it....Hi!
I am not sure anyone here is aware of it, but there's a wiki for the community/support team!
https://help.torproject.org/support/
This was managed by Lunar and hasn't been updated in about 6 years, so I doubt anyone still uses it. Since we migrated the TPA wiki (help.tpo) to gitlab (tpo/tpa/services#34437), we figured we would cleanup a few things and have simply removed that page from the new wiki:
https://gitlab.torproject.org/tpo/tpa/services/-/wikis/home
The help.tpo site will survive, as a redirect, however. I propose to redirect to support.torproject.org, since it's where support is organized nowadays.
Makes sense?https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/37sbws would use gitlab git as the canonical repo2020-06-25T11:34:21Zjugasbws would use gitlab git as the canonical repoAccording to what @ahf, @gk and i talked today, we would like to use the gitlab git as the canonical repo and then we can remove the git repo at git.tpoAccording to what @ahf, @gk and i talked today, we would like to use the gitlab git as the canonical repo and then we can remove the git repo at git.tpohttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40003Create a page in the wiki with a timeline of bandwith authority events2020-06-25T12:29:42ZjugaCreate a page in the wiki with a timeline of bandwith authority eventsThat would help to understand how changes in sbws or in the number of bwauths running torflow affects to the network.
Maybe that page should we moved to other namespace, since it is not only about sbws.That would help to understand how changes in sbws or in the number of bwauths running torflow affects to the network.
Maybe that page should we moved to other namespace, since it is not only about sbws.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40001Drop file size parameter on Timeouts and failures of downloading files over T...2020-06-25T19:43:17ZKarsten LoesingDrop file size parameter on Timeouts and failures of downloading files over Tor graph pageWe recently switched from downloading three different file sizes (50 KiB, 1 MiB, 5 MiB) to downloading just one file size (5 MiB). As a result, the [Timeouts and failures of downloading files over Tor](https://metrics.torproject.org/torp...We recently switched from downloading three different file sizes (50 KiB, 1 MiB, 5 MiB) to downloading just one file size (5 MiB). As a result, the [Timeouts and failures of downloading files over Tor](https://metrics.torproject.org/torperf-failures.html) graph is soon going to be blank for parameters 50 KiB or 1 MiB and only display dots for 5 MiB downloads.
There are several ways to deal with this:
1. We could change the default parameter value to 5 MiB.
2. We could redefine timeouts for smaller downloads, regenerate them, and analyze whether they have the same distribution.
3. We could drop the file size parameter and display all timeouts and failures together.
We briefly discussed this at the last team meeting, when I suggested the first option and @djackson suggested the second option. But I think the third option would be the simplest and be likewise appropriate. Recall that OnionPerf's timeouts only exist to avoid overlapping measurements, not to model realistic timeouts in the sense of a user giving up on a request.
Thoughts on going for option three?Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/162FA2020-06-26T06:51:24ZGabagaba@torproject.org2FAI think we should have 2FA in all admin accounts at least.I think we should have 2FA in all admin accounts at least.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40004Chutney tests failing now that AssumeReachable is off.2020-06-26T13:35:27ZNick MathewsonChutney tests failing now that AssumeReachable is off.Since I turned AssumeReachable off by default on relays, several chutney tests have become less reliable. I'll have to investigate why. Do we need a longer timeout?Since I turned AssumeReachable off by default on relays, several chutney tests have become less reliable. I'll have to investigate why. Do we need a longer timeout?Tor: 0.4.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-mobile/-/issues/4Establishing WebSocket connection with the Tor relay.2020-06-26T14:18:25ZHashikDEstablishing WebSocket connection with the Tor relay.In the service, the second part is to establish a connection with the Tor relay to send and receive the data.In the service, the second part is to establish a connection with the Tor relay to send and receive the data.https://gitlab.torproject.org/tpo/anti-censorship/emma/-/issues/2accounts.google.com is localised, which fails test for non-English environments2020-06-26T21:52:38ZPhilipp Winterphw@torproject.orgaccounts.google.com is localised, which fails test for non-English environmentsWe currently test if accounts.google.com is reachable by looking for the string "Sign in". In non-English environments, there is no such string. We need to be smarter about how we conduct this test.We currently test if accounts.google.com is reachable by looking for the string "Sign in". In non-English environments, there is no such string. We need to be smarter about how we conduct this test.https://gitlab.torproject.org/tpo/core/chutney/-/issues/34449There are too many networks in the chutney networks directory.2020-06-27T13:18:29ZNick 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 legacy/trac#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/tpo/core/chutney/-/issues/34448Chutney templates may need an option-fallback feature2020-06-27T13:18:29ZNick 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/tpo/core/chutney/-/issues/34447Chutney networks need at least 3 AssumeReachable nodes.2020-06-27T13:18:29ZNick 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 legacy/trac#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/tpo/core/chutney/-/issues/33957Unexpected keyword argument 'bufsize' in subprocess.check_output()2020-06-27T13:18:30ZteorUnexpected keyword argument 'bufsize' in subprocess.check_output()On some python versions, chutney's call to subprocess.check_output() results in the following error:
```
Unexpected keyword argument 'bufsize'…
```
https://github.com/torproject/chutney/pull/68#issuecomment-614596946
The check_output() ...On some python versions, chutney's call to subprocess.check_output() results in the following error:
```
Unexpected keyword argument 'bufsize'…
```
https://github.com/torproject/chutney/pull/68#issuecomment-614596946
The check_output() documentation is unclear about which arguments are supported: it simply says that most arguments to Popen() are supported. (And bufsize is an argument to Popen().):
https://docs.python.org/3.5/library/subprocess.html#subprocess.check_output
https://docs.python.org/3.5/library/subprocess.html#subprocess.Popen
I think our best option here is to remove the bufsize argument, and accept the default buffered behaviour.