Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:01:17Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33627Create bouncer account for chartor2020-06-13T17:01:17ZAntonelaantonela@torproject.orgCreate bouncer account for chartorI'm not sure if she needs an LDAP account for it. If that is a case, please also create it.
Once it is ready, please share the details with cpark@torproject.org
Thanks!I'm not sure if she needs an LDAP account for it. If that is a case, please also create it.
Once it is ready, please share the details with cpark@torproject.org
Thanks!pastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/32532Install ZNC on Chives, make pastly admin it2020-06-13T16:59:44ZpastlyInstall ZNC on Chives, make pastly admin itI think I want to migrate the TPO people who use my bouncer off my server and onto TPO infra. If possible.
Initial discussion with anarcat suggested that chives.tpo would be the box. Okay cool.
**Q1**: Can it get a valid TLS certificat...I think I want to migrate the TPO people who use my bouncer off my server and onto TPO infra. If possible.
Initial discussion with anarcat suggested that chives.tpo would be the box. Okay cool.
**Q1**: Can it get a valid TLS certificate? Both for the web interface (**edit** for account management, NOT CHAT) and also for protecting the IRC traffic.
**Q2**: Can Tor get installed on the box? Right now I also have an onion service pointing to my ZNC and it'd be cool to keep that.
If desired, I can talk more about how I have accomplished Q1 with Let's Encrypt, nginx, and a cron job. Q2 is just because it's easy and cool. No big deal.pastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/27960Cannot log to file because of typo in fs.py2020-06-13T16:14:02ZpastlyCannot log to file because of typo in fs.py```
Traceback (most recent call last):
File "/home/matt/src/simple-bw-scanner/venv-editable/bin/sbws", line 11, in <module>
load_entry_point('sbws', 'console_scripts', 'sbws')()
File "/home/matt/src/simple-bw-scanner/sbws/sbws.py...```
Traceback (most recent call last):
File "/home/matt/src/simple-bw-scanner/venv-editable/bin/sbws", line 11, in <module>
load_entry_point('sbws', 'console_scripts', 'sbws')()
File "/home/matt/src/simple-bw-scanner/sbws/sbws.py", line 56, in main
parser.description = sbws_required_disk_space(conf)
File "/home/matt/src/simple-bw-scanner/sbws/util/fs.py", line 68, in sbws_required_disk_space
num_log_files = conf.geting('logging', 'to_file_num_backups')
AttributeError: 'ConfigParser' object has no attribute 'geting'
```sbws: 1.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/27706Change sbws.rtfd.io to point to canonical GH repo2020-06-13T16:13:57ZjugaChange sbws.rtfd.io to point to canonical GH reposbws.rtfd.io is updated on pushes to gh/pastly/simple-bw-scanner. It should be changed now to get updated on pushes to gh/torproject/sbws.
This should be changed by pastly.sbws.rtfd.io is updated on pushes to gh/pastly/simple-bw-scanner. It should be changed now to get updated on pushes to gh/torproject/sbws.
This should be changed by pastly.sbws: 1.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/27398Create GH/torproject/sbws repository2020-06-13T16:55:29ZjugaCreate GH/torproject/sbws repositoryAs commented in network-team ml, we should create:
- a repository called sbws in GH/torproject
- give permissions to pastly, teor, juga to that repository
- push current GH/pastly/simple-bw-scanner master to it
- remove GH/torproject/si...As commented in network-team ml, we should create:
- a repository called sbws in GH/torproject
- give permissions to pastly, teor, juga to that repository
- push current GH/pastly/simple-bw-scanner master to it
- remove GH/torproject/simple-bw-scanner
When that is done, we can create other ticket to sync that repository with .git.tpo/sbwssbws: 1.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/27342sbws poor error handling2020-06-13T16:13:48ZTracsbws poor error handlingsbws first run states file not found, but gives no indication as to what file is not found.
```
test@26e7731456d9:~$ sbws scanner
Traceback (most recent call last):
File "/usr/lib/python3.5/logging/handlers.py", line 823, in _connect...sbws first run states file not found, but gives no indication as to what file is not found.
```
test@26e7731456d9:~$ sbws scanner
Traceback (most recent call last):
File "/usr/lib/python3.5/logging/handlers.py", line 823, in _connect_unixsocket
self.socket.connect(address)
FileNotFoundError: [Errno 2] No such file or directory
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/sbws", line 11, in <module>
sys.exit(main())
File "/usr/local/lib/python3.5/dist-packages/sbws/sbws.py", line 53, in main
configure_logging(args, conf)
File "/usr/local/lib/python3.5/dist-packages/sbws/util/config.py", line 160, in configure_logging
logging.config.fileConfig(fd.name)
File "/usr/lib/python3.5/logging/config.py", line 84, in fileConfig
handlers = _install_handlers(cp, formatters)
File "/usr/lib/python3.5/logging/config.py", line 148, in _install_handlers
h = klass(*args)
File "/usr/lib/python3.5/logging/handlers.py", line 806, in __init__
self._connect_unixsocket(address)
File "/usr/lib/python3.5/logging/handlers.py", line 834, in _connect_unixsocket
self.socket.connect(address)
FileNotFoundError: [Errno 2] No such file or directory
```
I assume the config file is missing, but don't know for sure.
**Trac**:
**Username**: gabesbws: 1.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/26881sbws isn't rotating its log files2020-06-13T16:13:37Zpastlysbws isn't rotating its log filesIdk wtf I was thinking when writing the code in `configure_logging()` to set up the RotatingFileHandler, but I didn't get its arguments correct.
Branch incoming shortly.
I've been running this for like a week now and it's actually rota...Idk wtf I was thinking when writing the code in `configure_logging()` to set up the RotatingFileHandler, but I didn't get its arguments correct.
Branch incoming shortly.
I've been running this for like a week now and it's actually rotating files now.sbws: 1.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/24254There needs to be documentation on what kernel versions the KIST Scheduler wi...2020-06-13T15:17:21ZTracThere needs to be documentation on what kernel versions the KIST Scheduler will run onThere needs to be decimation on what kernel versions the KIST Scheduler will run on. Right now I'm running
Ubuntu 16.04.3 LTS (GNU/Linux 2.6.32-042stab120.11 x86_64) and it looks like it is running based off the logs.
**Trac**:
**Use...There needs to be decimation on what kernel versions the KIST Scheduler will run on. Right now I'm running
Ubuntu 16.04.3 LTS (GNU/Linux 2.6.32-042stab120.11 x86_64) and it looks like it is running based off the logs.
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/24158I get this error "Looks like our kernel doesn't have the support for KIST any...2020-06-13T15:17:00ZTracI get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relayIm running a tor relay, running tor-0.3.2.3-alpha and I keep getting this error.
[notice] Looks like our kernel doesn't have the support for KIST anymore. We will fallback to the naive approach. Remove KIST from the Schedulers list to di...Im running a tor relay, running tor-0.3.2.3-alpha and I keep getting this error.
[notice] Looks like our kernel doesn't have the support for KIST anymore. We will fallback to the naive approach. Remove KIST from the Schedulers list to disable.
Relay kernel, GNU/Linux 2.6.32-042stab111.12 x86_64
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/24135fluxe4 (a fallback dir) has stable ipv62020-06-13T16:06:09ZSebastian Hahnfluxe4 (a fallback dir) has stable ipv6It is 2001:638:a000:4140::ffff:188It is 2001:638:a000:4140::ffff:188Tor: 0.3.3.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/23581Die more helpfully if Schedulers option isn't compatible with platform2020-06-13T15:14:15ZpastlyDie more helpfully if Schedulers option isn't compatible with platformKIST isn't supported on OS X. The user is being dumb and setting `Schedulers` to just KIST, so we can't fallback to KISTLite or even Vanilla. Therefore `select_scheduler()` doesn't set `the_scheduler` and thus `the_scheduler->init()` doe...KIST isn't supported on OS X. The user is being dumb and setting `Schedulers` to just KIST, so we can't fallback to KISTLite or even Vanilla. Therefore `select_scheduler()` doesn't set `the_scheduler` and thus `the_scheduler->init()` doesn't work in `set_scheduler()`.
This isn't a problem during a HUP because we already have a scheduler. `select_scheduler()` doesn't change anything and we keep on running with whatever scheduler we were using before.
```
cranium:tor mtraudt$ cat torrc
DataDirectory data
PidFile data/tor.pid
Socks5Proxy 127.0.0.1:2343
Schedulers KIST
Log [sched]info [~sched]notice stdout
```
```
cranium:tor mtraudt$ ./src/or/tor -f torrc
Sep 19 09:33:26.370 [notice] Tor 0.3.2.1-alpha-dev (git-472858d629252ae8) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.5, Liblzma 5.2.3, and Libzstd N/A.
Sep 19 09:33:26.371 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 19 09:33:26.371 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 19 09:33:26.371 [notice] Read configuration file "/private/tmp/tor/torrc".
Sep 19 09:33:26.373 [warn] Path for DataDirectory (data) is relative and will resolve to /private/tmp/tor/data. Is this what you wanted?
Sep 19 09:33:26.374 [warn] Path for PidFile (data/tor.pid) is relative and will resolve to /private/tmp/tor/data/tor.pid. Is this what you wanted?
============================================================ T= 1505828006
Tor 0.3.2.1-alpha-dev (git-472858d629252ae8) died: Caught signal 11
0 tor 0x000000010a4e38d9 crash_handler + 57
1 libsystem_platform.dylib 0x00007fff9307d52a _sigtramp + 26
2 tor 0x000000010a4d2a84 set_scheduler + 164
3 tor 0x000000010a4d34eb scheduler_init + 347
4 tor 0x000000010a346115 options_act_reversible + 453
5 tor 0x000000010a345c24 set_options + 68
6 tor 0x000000010a350991 options_init_from_string + 1697
7 tor 0x000000010a34fa27 options_init_from_torrc + 1399
8 tor 0x000000010a42f833 tor_init + 1523
9 tor 0x000000010a430147 tor_main + 103
10 tor 0x000000010a2fb350 main + 48
11 libdyld.dylib 0x00007fff9e1765ad start + 1
Abort trap: 6
```Tor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/23566options/validate__transproxy fails on FreeBSD (thanks to the new scheduler)2020-06-13T15:14:05Zpastlyoptions/validate__transproxy fails on FreeBSD (thanks to the new scheduler)Introduced in b2c56eacdd61429f17b9e14db665592ac4453c50 according to git bisect.
```
sched: Remove vanilla sched options that will be going away
- massive change to src/tgest/test_options.c since the sched options
were add...Introduced in b2c56eacdd61429f17b9e14db665592ac4453c50 according to git bisect.
```
sched: Remove vanilla sched options that will be going away
- massive change to src/tgest/test_options.c since the sched options
were added all over the place in it
- removing the sched options caused some tests to pass/fail in new ways
so I assumed current behavior is correct and made them pass again
- ex: "ConnLimit must be greater" lines
- ex: "Authoritative directory servers must" line
- remove test_options_validate__scheduler in prep for new sched tests
```
And guess why it fails.
```
options/validate__transproxy: [forking]
FAIL src/test/test_options.c:1129: Expected NULL but got 'ConnLimit must be greater than 0, but was set to 0'
[validate__transproxy FAILED]
```Tor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/23560Fix typo(s) in comment(s) in the scheduling system.2020-06-13T15:14:02ZpastlyFix typo(s) in comment(s) in the scheduling system.First one:
```
if (diff < sched_run_interval) {
next_run.tv_sec = 0;
/* Takes 1000 ms -> us. This will always be valid because diff can NOT be
- * negative and can NOT be smaller than sched_run_interval so values can
+...First one:
```
if (diff < sched_run_interval) {
next_run.tv_sec = 0;
/* Takes 1000 ms -> us. This will always be valid because diff can NOT be
- * negative and can NOT be smaller than sched_run_interval so values can
+ * negative and can NOT be bigger than sched_run_interval so values can
```
There's no way there isn't more, so I'm making this a generalized ticket.Tor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/23552We don't need to log our scheduler type so often2020-06-13T15:14:00ZpastlyWe don't need to log our scheduler type so oftenThis is silly.
```
Sep 16 20:54:07.473 [notice] Tor 0.3.2.0-alpha-dev (git-4519b7b469635686) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Sep 16 20:54:07.473 [notice] Tor can'...This is silly.
```
Sep 16 20:54:07.473 [notice] Tor 0.3.2.0-alpha-dev (git-4519b7b469635686) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Sep 16 20:54:07.473 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 16 20:54:07.473 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 16 20:54:07.473 [notice] Read configuration file "/home/matt/src/tor/torrc".
Sep 16 20:54:07.475 [warn] Path for DataDirectory (data) is relative and will resolve to /home/matt/src/tor/data. Is this what you wanted?
Sep 16 20:54:07.475 [warn] Path for HiddenServiceDir (data/hs1) is relative and will resolve to /home/matt/src/tor/data/hs1. Is this what you wanted?
Sep 16 20:54:07.475 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
Sep 16 20:54:07.476 [notice] Scheduler type KIST has been enabled.
Sep 16 20:54:07.476 [notice] Opening Socks listener on 127.0.0.1:23456
Sep 16 20:54:07.476 [notice] Opening Control listener on 127.0.0.1:12345
Sep 16 20:54:07.476 [warn] Your log may contain sensitive information - you disabled SafeLogging. Don't log unless it serves an important reason. Overwrite the log afterwards.
Sep 16 20:54:07.477 [notice] Scheduler type KIST has been enabled.
Sep 16 20:54:07.680 [notice] Bootstrapped 0%: Starting
Sep 16 20:54:07.833 [notice] Scheduler type KIST has been enabled.
Sep 16 20:54:08.009 [notice] Starting with guard context "default"
Sep 16 20:54:08.014 [notice] Bootstrapped 80%: Connecting to the Tor network
Sep 16 20:54:08.757 [notice] Bootstrapped 85%: Finishing handshake with first hop
Sep 16 20:54:11.319 [notice] Bootstrapped 90%: Establishing a Tor circuit
Sep 16 20:54:13.575 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 16 20:54:13.575 [notice] Bootstrapped 100%: Done
Sep 16 20:54:15.049 [notice] Scheduler type KIST has been enabled.
Sep 16 22:23:16.435 [notice] Scheduler type KIST has been enabled.
Sep 17 00:18:14.736 [notice] Scheduler type KIST has been enabled.
Sep 17 01:32:13.524 [notice] Scheduler type KIST has been enabled.
Sep 17 02:54:08.478 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 15 circuits open. I've sent 1.70 MB and received 3.21 MB.
Sep 17 03:20:14.427 [notice] Scheduler type KIST has been enabled.
Sep 17 05:00:11.271 [notice] Scheduler type KIST has been enabled.
Sep 17 06:46:11.481 [notice] Scheduler type KIST has been enabled.
Sep 17 08:06:14.916 [notice] Scheduler type KIST has been enabled.
Sep 17 08:54:08.480 [notice] Heartbeat: Tor's uptime is 11:59 hours, with 15 circuits open. I've sent 2.90 MB and received 6.01 MB.
Sep 17 09:18:12.910 [notice] Scheduler type KIST has been enabled.
Sep 17 11:15:13.930 [notice] Scheduler type KIST has been enabled.
Sep 17 12:21:16.363 [notice] Scheduler type KIST has been enabled.
```
I think we just want to log once on startup, then log only if it changes.Tor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/23537Allow the new sched to respond to a new conensus, not the old one.2020-06-13T15:13:56ZpastlyAllow the new sched to respond to a new conensus, not the old one.If the sched hears about a new consensus, we should switch schedulers first. Then tell the scheduler implementation about the new consensus. It doesn't make sense to have the old one respond to the new consensus right before we stop usin...If the sched hears about a new consensus, we should switch schedulers first. Then tell the scheduler implementation about the new consensus. It doesn't make sense to have the old one respond to the new consensus right before we stop using it.
```
@@ -371,12 +369,13 @@ void
scheduler_notify_networkstatus_changed(const networkstatus_t *old_c,
const networkstatus_t *new_c)
{
+ /* Maybe the consensus param made us change the scheduler. */
+ set_scheduler();
+
/* Then tell the (possibly new) scheduler that we have a new consensus */
if (the_scheduler->on_new_consensus) {
the_scheduler->on_new_consensus(old_c, new_c);
}
- /* Maybe the consensus param made us change the scheduler. */
- set_scheduler();
}
/*
```Tor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/22527Add new operators to fallback directory whitelist2020-06-13T16:06:07ZteorAdd new operators to fallback directory whitelistI will keep a list here, and do them all at once.I will keep a list here, and do them all at once.Tor: 0.3.3.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/17598Trace cell queue times in Tor to measure Tor application "congestion"2020-06-13T14:50:59ZRob JansenTrace cell queue times in Tor to measure Tor application "congestion"In order to do #12892, we need to be able to measure congestion in the kernel **and** congestion in Tor. For the kernel, we can use libkqtime:
https://github.com/robgjansen/libkqtime
This ticket is to add the components needed to comput...In order to do #12892, we need to be able to measure congestion in the kernel **and** congestion in Tor. For the kernel, we can use libkqtime:
https://github.com/robgjansen/libkqtime
This ticket is to add the components needed to compute Tor congestion, as part of dgoulet's new instrumentation framework.Tor: unspecifiedpastlypastlyhttps://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-finalpastlypastly