The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-08-02T00:02:28Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30579Add more STUN servers to the default snowflake configuration in Tor Browser2023-08-02T00:02:28ZCecylia BocovichAdd more STUN servers to the default snowflake configuration in Tor BrowserRight now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying...Right now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying to block snowflake so that blocking this stage causes more collateral damage.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40383daily abort in tor 0.4.5.7, 0.4.6.1-alpha, and 0.4.6.2-alpha [Assertion end >...2023-01-10T18:36:20ZScott Bennettdaily abort in tor 0.4.5.7, 0.4.6.1-alpha, and 0.4.6.2-alpha [Assertion end > start failed in create_voting_schedule]### Summary
I was running 0.4.5.2-alpha with no problems. After I upgraded tor to 0.4.6.1-alpha,
tor crashed in under 24 hours. After the third such crash, I switched to 0.4.5.7,
naively expecting it to be a "stable" release. That vers...### Summary
I was running 0.4.5.2-alpha with no problems. After I upgraded tor to 0.4.6.1-alpha,
tor crashed in under 24 hours. After the third such crash, I switched to 0.4.5.7,
naively expecting it to be a "stable" release. That version, too, crashes with the
same set of error messages. I have now upgraded to 0.4.6.2-alpha, and the same bug
is present. I am running tor on a FreeBSD 11.4-STABLE system.
### Steps to reproduce:
1. Install one of the afflicted versions of tor onto a FreeBSD 11.4-STABLE system. I do not
know whether later versions of FreeBSD would get a different result, but given the abort
messages, I suspect not.
2. Start tor.
3. Wait until 6 p.m. CDT (2300Z). The abort will occur before 7 p.m. CDT (0000Z).
### What is the current bug behavior?
During startup and operation everything appears to be normal. However, these versions
of tor always abort every day between 6 p.m. and 7 p.m. CDT (2300Z and 0000Z) with the
same group of error messages being written to /var/log/notices.
The startup messages look as follows.
```
May 08 19:21:24.633 [notice] Tor 0.4.6.2-alpha opening log file.
May 08 19:21:24.601 [notice] We compiled with OpenSSL 101010bf: OpenSSL 1.1.1k 25 Mar 2021 and we are running with OpenSSL 101010bf: 1.1.1k. These two versions should be binary compatible.
May 08 19:21:24.604 [notice] Tor 0.4.6.2-alpha running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.9 and Unknown N/A as libc.
May 08 19:21:24.604 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 08 19:21:24.604 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 08 19:21:24.604 [notice] Read configuration file "/usr/local/etc/tor/torrc".
May 08 19:21:24.616 [notice] You configured a non-loopback address '10.1.1.1:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
May 08 19:21:24.616 [notice] Opening Socks listener on 127.0.0.1:9050
May 08 19:21:24.616 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
May 08 19:21:24.616 [notice] Opening Socks listener on 10.1.1.1:9050
May 08 19:21:24.616 [notice] Opened Socks listener connection (ready) on 10.1.1.1:9050
May 08 19:21:24.616 [notice] Opening Control listener on 127.0.0.1:9051
May 08 19:21:24.616 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
May 08 19:21:24.616 [notice] Opening OR listener on 0.0.0.0:32323
May 08 19:21:24.616 [notice] Opened OR listener connection (ready) on 0.0.0.0:32323
May 08 19:21:24.616 [notice] Opening Directory listener on 0.0.0.0:32326
May 08 19:21:24.616 [notice] Opened Directory listener connection (ready) on 0.0.0.0:32326
May 08 19:21:24.640 [notice] Not disabling debugger attaching for unprivileged users.
May 08 19:21:25.419 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 08 19:21:25.593 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 08 19:21:25.756 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
May 08 19:21:25.907 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 0861F4966E199C0BA9DB1D904DB4BC843508F12C'
May 08 19:21:25.907 [notice] Your Tor server's identity key ed25519 fingerprint is 'MYCROFTsOtherChild hYNLQhYYu0FRDfZGPVW3jFPW27tHY6fZm0GiFP2YkPE'
May 08 19:21:25.907 [notice] Bootstrapped 0% (starting): Starting
May 08 19:21:43.556 [notice] Starting with guard context "default"
May 08 19:21:44.605 [notice] Bootstrapped 5% (conn): Connecting to a relay
May 08 19:21:44.718 [notice] Bootstrapped 10% (conn_done): Connected to a relay
May 08 19:21:44.962 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
May 08 19:21:45.447 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
May 08 19:21:45.448 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
May 08 19:21:45.448 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
May 08 19:21:45.448 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
May 08 19:21:48.184 [notice] Bootstrapped 100% (done): Done
May 08 19:21:48.185 [notice] Now checking whether IPv4 ORPort 98.193.69.56:32323 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
May 08 19:21:48.649 [notice] Self-testing indicates your ORPort 98.193.69.56:32323 is reachable from the outside. Excellent. Publishing server descriptor.
May 08 19:39:45.296 [notice] Performing bandwidth self-test...done.
```
The abort messages follow. It does not appear to matter what time of day tor is started.
It always aborts during that hour at the start of the evening, and the exact time seems to be
quasi-random and may coincide with some quasi-hourly event, such as downloading directory
updates or consensus files.
```
May 09 18:21:45.586 [notice] Heartbeat: Tor's uptime is 23:00 hours, with 88 circuits open. I've sent 1.18 GB and received 1.46 GB. I've received 12680 connections on IPv4 and 0 on IPv6. I've made 11044 connections with IPv4 and 0 with IPv6.
May 09 18:21:45.620 [notice] While bootstrapping, fetched this many bytes: 35042 (consensus network-status fetch); 500 (microdescriptor fetch)
May 09 18:21:45.620 [notice] While not bootstrapping, fetched this many bytes: 13502874 (server descriptor fetch); 1080 (server descriptor upload); 1780039 (consensus network-status fetch); 89127 (microdescriptor fetch)
May 09 18:21:45.620 [notice] Circuit handshake stats since last time: 11/11 TAP, 1449/1449 NTor.
May 09 18:21:45.620 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 511 v4 connections; initiated 10070 and received 11411 v5 connections.
May 09 18:21:45.620 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected.
May 09 18:23:46.805 [err] tor_assertion_failed_: Bug: src/feature/dirauth/voting_schedule.c:64: create_voting_schedule: Assertion end > start failed; aborting. (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: Tor 0.4.6.2-alpha: Assertion end > start failed in create_voting_schedule at src/feature/dirauth/voting_schedule.c:64: . Stack trace: (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1107fac <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11132a2 <tor_assertion_failed_+0x142> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x10e96a6 <dirauth_sched_recalculate_timing+0x1e6> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x109c113 <networkstatus_set_current_consensus+0xed3> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11d96cc <connection_dir_reached_eof+0x1b6c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11acf26 <connection_handle_read+0xbe6> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1090050 <connection_add_impl+0x240> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1c1bada8a <event_base_assert_ok_nolock_+0xc3a> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1c1ba8eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1092465 <do_main_loop+0x135> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.807 [err] Bug: 0x108d89c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.807 [err] Bug: 0x108c22e <tor_main+0x6e> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
```
### What is the expected behavior?
I expect tor not to abort and instead to run until either I shut it down or the OS crashes
for any reason.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
As stated above, the versions I know to be affected are 0.4.5.7, 0.4.6.1-alpha, and
0.4.6.2-alpha.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10,
Ubuntu Xenial, FreeBSD 12.2, etc.
As stated above, this problem is occurring on FreeBSD 11.4-STABLE. I have added an
entry to /etc/crontab to restart tor every evening at 7:01 p.m. CDT (2301Z), which works,
but does not prevent sudden breakage of about 400 to 2000 connections when tor aborts, and
means that my relay can never get a Stable flag. (The authorities stopped giving it a
HSDir flag months ago for no reason apparent to me, as well, but that appears to be a problem unrelated to the bug reported here.)
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
I installed each version using portmaster(8) to install/upgrade from the FreeBSD
11-STABLE ports tree, so portmaster compiled each version locally. Other than the kinds of
differences that show up when not using a "reproducible build" procedure, they are the same
as if installed by pkg(8).
### Relevant logs and/or screenshots
See above.
### Possible fixesTor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40712Unable to set a primary password on TB112023-11-12T03:48:11ZdonutsUnable to set a primary password on TB11Although the password manager is not officially supported by Tor Browser, I fear we may have inadvertently broken it again. Occurs on all desktop platforms as far as I can tell.
![tb-11-primary-password](/uploads/e40f3b2993253ffac6d8162...Although the password manager is not officially supported by Tor Browser, I fear we may have inadvertently broken it again. Occurs on all desktop platforms as far as I can tell.
![tb-11-primary-password](/uploads/e40f3b2993253ffac6d8162719fe8081/tb-11-primary-password.png)Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40544Show tor's bootstrapping percentage and description on about:torconnect2022-05-17T23:09:26ZMatthew FinkelShow tor's bootstrapping percentage and description on about:torconnectIt's written on the label.
Possible backport candidate.It's written on the label.
Possible backport candidate.Tor Browser: 11.0 Issues with previous releaserichardrichardhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40450The old website build is breaking because it does not find the tor repo2021-10-20T13:49:37ZemmapeelThe old website build is breaking because it does not find the tor repoThere is a new error in town, and it is jenkins complaining it cannot build the 'old website':
`[jenkins] website-build-webwml#8911: Still Failing: https://jenkins.torproject.org/job/website-build-webwml/8911/
`
If you open the job you...There is a new error in town, and it is jenkins complaining it cannot build the 'old website':
`[jenkins] website-build-webwml#8911: Still Failing: https://jenkins.torproject.org/job/website-build-webwml/8911/
`
If you open the job you can see that the build breaks because of:
```
15:13:59 > git config remote.origin.url https://git.torproject.org/tor.git # timeout=10
15:13:59 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
15:13:59 Avoid second fetch
15:13:59 > git rev-parse origin/master^{commit} # timeout=10
15:13:59 > git rev-parse master^{commit} # timeout=10
15:13:59 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
```
I am not sure that we need to run it so often, now that it is not having any new content.
But if we do, we should change the reference. Maybe is the move from master to main?Retire Jenkinshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30832Fix tor-browser tbb-tests2022-07-08T23:11:04ZAlex CatarineuFix tor-browser tbb-testsWith current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart f...With current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart from disabling tor-launcher. The second pref disables the domain isolator, which makes sense since it expects SOCKS5 proxies, but mochitests override that. For the other pref, not sure why `network.file.path_blacklist` needs to be unset (at least for Linux).
We could put these prefs in `testing/marionette/prefs/marionette.js` so that tests can be run (unless there is a simpler way to get the tests tor run that I'm missing).Tor Browser: 10.5https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33832For relays that change ip, only the measurements with the last ip are kept2020-12-18T09:41:15ZjugaFor relays that change ip, only the measurements with the last ip are keptwhich makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.which makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/32868crash: Assertion node->rs->is_possible_guard failed in compute_weighted_band...2020-07-14T22:24:21Ztoralfcrash: Assertion node->rs->is_possible_guard failed in compute_weighted_bandwidths atWith https://github.com/toralf/torutils/blob/f307866d2149bcd3c95df5269b3b48d051f871e9/info.py I monitor the status of my 2 Tor relays. A day before I commented out this section in torrc:
```
#FetchDirInfoEarly 1
#FetchDirInfoExtraEarly 1...With https://github.com/toralf/torutils/blob/f307866d2149bcd3c95df5269b3b48d051f871e9/info.py I monitor the status of my 2 Tor relays. A day before I commented out this section in torrc:
```
#FetchDirInfoEarly 1
#FetchDirInfoExtraEarly 1
#FetchUselessDescriptors 1
#UseMicrodescriptors 0
#DownloadExtraInfo 1
```
Now it took 7 minutes to finish (when those config values were set it was much faster).
But more interesting I realized today I crash of one of both Tor relays:
```
Jan 01 11:12:38.000 [warn] compute_weighted_bandwidths(): Bug: Consensus is missing some bandwidths. Using a naive router selection algorithm (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] tor_assertion_failed_(): Bug: src/feature/nodelist/node_select.c:723: compute_weighted_bandwidths: Assertion node->rs->is_possible_guard failed; aborting. (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: Tor 0.4.2.5: Assertion node->rs->is_possible_guard failed in compute_weighted_bandwidths at src/feature/nodelist/node_select.c:723: . Stack trace: (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x59) [0x55850995e1a9] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x150) [0x5585099593e0] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(+0x12c474) [0x558509896474] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(frac_nodes_with_descriptors+0x73) [0x558509897373] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(+0x12afb2) [0x558509894fb2] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(count_loading_descriptors_progress+0x6c) [0x558509895b2c] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(connection_dir_reached_eof+0x20e0) [0x558509856f30] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(connection_handle_read+0x980) [0x5585097d2760] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(+0x6d97c) [0x5585097d797c] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/lib64/libevent-2.1.so.6(+0x219ca) [0x7ffbba3cb9ca] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/lib64/libevent-2.1.so.6(event_base_loop+0x4ef) [0x7ffbba3cc54f] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(do_main_loop+0xdd) [0x5585097d8b2d] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(tor_run_main+0x10c5) [0x5585097c6855] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(tor_main+0x46) [0x5585097c4076] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(main+0x19) [0x5585097c3c49] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ffbb9d19eab] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x5585097c3c9a] (on Tor 0.4.2.5 )
```
System is a hardened Gentoo Linux running 2 relays. The second is not affected.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40262Browser tabs crashing on the new Macbooks with the M1 chip2021-01-16T16:15:29Zchampionquizzerchampionquizzer@torproject.orgBrowser tabs crashing on the new Macbooks with the M1 chipThere are recurring reports from users on the frontdesk that the latest version of Tor Browser (10.0.5) and Tor Browser Alpha (10.5a4) for the MacOS on the new Macbooks with the M1 chip, keeps crashing with the error message "Gah. Your t...There are recurring reports from users on the frontdesk that the latest version of Tor Browser (10.0.5) and Tor Browser Alpha (10.5a4) for the MacOS on the new Macbooks with the M1 chip, keeps crashing with the error message "Gah. Your tab just crashed"Tor Browser: 10.0https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33666Investigate Snowflake proxy failures2022-06-01T19:51:48ZCecylia BocovichInvestigate Snowflake proxy failuresSometimes a client will get a useless proxy from the broker. At times this happens occasionally, and at times more often. It could be a NAT problem.Sometimes a client will get a useless proxy from the broker. At times this happens occasionally, and at times more often. It could be a NAT problem.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-09-23T13:43:20ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41222Is the web ui disabled for our VictoriaMetrics version?2023-06-13T12:37:36ZHiroIs the web ui disabled for our VictoriaMetrics version?I see the web ui for VictoriaMetrics at https://metrics-db.torproject.org/vmui/ is returning a 404.
\@gkI see the web ui for VictoriaMetrics at https://metrics-db.torproject.org/vmui/ is returning a 404.
\@gkSponsor 112 : Combating Malicious RelaysJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40798TPA-RFC-31: outsource email services2022-12-05T18:53:38ZanarcatTPA-RFC-31: outsource email servicesThe proposal to host the entirety of our email services in-house, TPA-RFC-15, was officially rejected (see tpo/tpa/team#40363 and wiki-replica@ea20e615 for details). Now we need to figure out which part of email we'll outsource, and to ...The proposal to host the entirety of our email services in-house, TPA-RFC-15, was officially rejected (see tpo/tpa/team#40363 and wiki-replica@ea20e615 for details). Now we need to figure out which part of email we'll outsource, and to whom.
This ticket is to track the drafting and adoption of that proposal. Once that's done, new tickest should be created for those individual tasks.
quick brainstorm of a checklist:
- [x] brainstorm requirements here
- [x] adopt requirements
- [x] figure out what we'll do with the existing email services (e.g. probably retire submission?)
- [x] personas
- [x] list possible providers
- [x] generic
- [x] transactional
- [x] checkin with isa about what SLA we want
- [ ] officialize quotes, don't forget to mention SLA
- [ ] costs
- [x] staff, setup
- [x] staff, ongoing
- [ ] hosting
- [ ] timeline
- [ ] approval: same as TPA-RFC-15? (TPA, internal, ops, in that order?)
- [ ] deadline: maybe draft this within 2-3 weeks max, adoption in 4-6 weeks?
- [ ] review TPA-RFC-15 to see if we forgot any bits
any other ideas?
draft lives in https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-31-outsource-emailimprove mail servicesanarcatanarcat2022-12-08https://gitlab.torproject.org/tpo/tpa/team/-/issues/40765User reporting "gmail couldn't verify whether it accually came from torprojec...2022-12-15T21:04:22Zal smithUser reporting "gmail couldn't verify whether it accually came from torproject.org" messageHi TPA, I'm passing along an issue that a user reported to me regarding our newsletter:
> I receive your newsletter and thanks for that!
> Now Gmail puts a warning about spam or malware on the mail.
> I would like to know your opinion o...Hi TPA, I'm passing along an issue that a user reported to me regarding our newsletter:
> I receive your newsletter and thanks for that!
> Now Gmail puts a warning about spam or malware on the mail.
> I would like to know your opinion on that.
> Should I worry?
>
> I link a pic to this mail to show you what it's all about!
>
> ![Screen_Shot_2022-05-18_at_10.43.53_AM](/uploads/3500a6cfdcfb904d0d58a66832f934f1/Screen_Shot_2022-05-18_at_10.43.53_AM.png)
>
> (It's in danish - I'll translate it:) Be careful with this message. Gmail couldn't verify whether it actually came from torproject.org.
> Avoid clicking links, downloading files or answering this message with personal data!
>
> What do you think of this?improve mail serviceshttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40640Gmail rejects mail from submission.tpo as spam from time to time2022-12-15T20:33:26ZGeorg KoppenGmail rejects mail from submission.tpo as spam from time to timeThis is at least the second case where a mail I sent to a Gmail address bounces back and could not get delivered (I needed to fall back to using Riseup). Here is what I got (the mail address I sent to being redacted):
```
This is the mai...This is at least the second case where a mail I sent to a Gmail address bounces back and could not get delivered (I needed to fall back to using Riseup). Here is what I got (the mail address I sent to being redacted):
```
This is the mail system at host submit-01.torproject.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<XXX@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4010:c02::1b]
said: 550-5.7.26 This message does not have authentication information or
fails to 550-5.7.26 pass authentication checks. To best protect our users
from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26
https://support.google.com/mail/answer/81126#authentication for more 550
5.7.26 information. o25-20020ac24359000000b004437b0e446asi11253489lfl.62 -
gsmtp (in reply to end of DATA command)
Reporting-MTA: dns; submit-01.torproject.org
X-Postfix-Queue-ID: A948A80095
X-Postfix-Sender: rfc822; gk@torproject.org
Arrival-Date: Tue, 1 Mar 2022 08:03:06 +0000 (UTC)
Final-Recipient: rfc822; XXX@gmail.com
Original-Recipient: rfc822;XXX@gmail.com
Action: failed
Status: 5.7.26
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.26 This message does not have authentication
information or fails to 550-5.7.26 pass authentication checks. To best
protect our users from spam, the 550-5.7.26 message has been blocked.
Please visit 550-5.7.26
https://support.google.com/mail/answer/81126#authentication for more 550
5.7.26 information. o25-20020ac24359000000b004437b0e446asi11253489lfl.62 -
gsmtp
```improve mail serviceshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27202Tor unable to bind one of the listener ports2020-06-27T14:35:19ZTracTor unable to bind one of the listener portsWhen trying to reconnect to tor browser, the error code shows up saying that it can not bind one of the listener ports and will not let me continue. I've tried redownloading the application and it still does the same thing. I can't seem ...When trying to reconnect to tor browser, the error code shows up saying that it can not bind one of the listener ports and will not let me continue. I've tried redownloading the application and it still does the same thing. I can't seem to figure out what the issue is.
**Trac**:
**Username**: DfrostyTor: unspecifiedhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/30174possible SBWS measurement quality regression2022-02-17T09:18:41Zstarlightpossible SBWS measurement quality regressionWith the release of v1.1 to longclaw seeing evidence of measurement quality degradation, regression. Have not had time to work up an analysis.
Recommend running Matt's original scanner and comparing raw bandwidth results.With the release of v1.1 to longclaw seeing evidence of measurement quality degradation, regression. Have not had time to work up an analysis.
Recommend running Matt's original scanner and comparing raw bandwidth results.sbws: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32218Systemd problem with ExecReload and CAP_KILL2020-07-27T19:39:02ZTracSystemd problem with ExecReload and CAP_KILLHi
There is a known issue with CGroup hardening which systemd applies, that without CAP_KILL capability, it's not possible to send HUP signal by managed slice, even to MAINPID.
Please add it to CapabilityBoundingSet= section in unit file...Hi
There is a known issue with CGroup hardening which systemd applies, that without CAP_KILL capability, it's not possible to send HUP signal by managed slice, even to MAINPID.
Please add it to CapabilityBoundingSet= section in unit file.
Running Tor 0.4.2.2-alpha on Gentoo.
https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in?id=d5cbc58094ec740e768d5fa88a51c20c645ed70e
**Trac**:
**Username**: sunovaTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31149Tor is stuck at "Loading Network Status"2020-07-29T12:41:21ZTracTor is stuck at "Loading Network Status"Tor Version: 8.5.4
Operating System: Windows 7
This is the Log I get after clicking:https://paste2.org/mUggK824
**Trac**:
**Username**: bornadxTor Version: 8.5.4
Operating System: Windows 7
This is the Log I get after clicking:https://paste2.org/mUggK824
**Trac**:
**Username**: bornadxTor: unspecified