The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-12-21T09:04:03Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42300Do not store logs inside TorProvider2023-12-21T09:04:03ZPier Angelo VendrameDo not store logs inside TorProviderDropping the entire `TorProvider` in case of failure has some advantages, but also a big disadvantage: logs are stored in the `TorProvider` object.
When we drop it we also drop logs.
If Tor died for an actual bug/problem, we remove the ...Dropping the entire `TorProvider` in case of failure has some advantages, but also a big disadvantage: logs are stored in the `TorProvider` object.
When we drop it we also drop logs.
If Tor died for an actual bug/problem, we remove the way of knowing that.
So, we shouldn't store the logs in the provider, but store them elsewhere.
/related #41921https://gitlab.torproject.org/tpo/core/tor/-/issues/40901Document for the Relay Operator community how to debug relays that are slower...2023-12-19T07:53:56ZAlexander Færøyahf@torproject.orgDocument for the Relay Operator community how to debug relays that are slower than what the operator expectsThis idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more...This idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more|less) memory/crashes (more|less) often/etc. many of these items are hard to give a definitive "yes, the cause of this is X" and it's very time consuming for the Network Team to debug each item individually with the operator.
It would be very useful to have a document in place that informs relay operators about the different situations that may impact performance and how they can get some performance measurements they can then compare to and see if our performance have truly regressed. This can also be used to push MetricsPort to more operators.
We can expand upon the document over time as we discover new ways to do this analysis and/or from feedback from the relay operator community.
This is related to:
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021409.html
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021407.html
This may be relevant to Arti Relay too.
CC @mikeperry for awareness.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176run some experiments with CAPTCHAs2023-12-18T18:28:37Zmeskiomeskio@torproject.orgrun some experiments with CAPTCHAsAs we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it...As we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it in the HTTPS distributor as soon as we have migrated it to rdsys (#2).
There was a thread in the mailing list some years ago about this:
https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html
We should explore the space and see what better options for CAPTCHAs exist now a days.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41988Tor Browser history leaked to syslogs via GNOME2023-12-18T13:51:55ZhonortonTor Browser history leaked to syslogs via GNOME### Summary
Tab titles are sometimes logged by GNOME to `/var/log/syslog`, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not...### Summary
Tab titles are sometimes logged by GNOME to `/var/log/syslog`, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not expect this.
### Steps to reproduce:
1. Open a new Tor Browser window.
2. (optional) "Connect" to the Tor network and navigate to an arbitrary website.
3. Press the Super key (default) to open the GNOME activities menu.
4. Review syslog via `cat /var/log/syslog | grep -i "browser"`
### What is the current bug behavior?
I see results containing Tor Browser tab titles, such as the titles of opened websites.
### What is the expected behavior?
I expect not to see my visited website titles in any system file without my authorization.
More strongly, I don't expect GNOME (which may log all sorts of things) to require access to my visited website titles.
### Environment
- OS Version: Pop! OS 22.04
- GNOME Shell Version: 3.38.6
- Tor Browser Version: 12.5.2
- Tor Browser Installation Method: "Linux" binary from `https://www.torproject.org/download/`
### Relevant logs and/or screenshots
```
[/var/log/syslog]
[snip]
Aug 9 11:23:52 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug 9 11:23:53 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug 9 11:27:28 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
Aug 9 11:27:31 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
[snip]
```Pier Angelo VendramePier Angelo Vendrame2023-11-13https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17560Downloaded URLs disk leak on Linux2023-12-18T10:10:42ZGeorg KoppenDownloaded URLs disk leak on LinuxA user on the blog (https://blog.torproject.org/blog/tor-browser-504-released#comment-114195) mentioned that Browser/.local/share/gvfs-metadata/ leaks the URLs downloaded.A user on the blog (https://blog.torproject.org/blog/tor-browser-504-released#comment-114195) mentioned that Browser/.local/share/gvfs-metadata/ leaks the URLs downloaded.ma1ma1https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40303Show number of currently open connections in hourly standalone proxy log output2023-12-13T19:18:04ZCecylia BocovichShow number of currently open connections in hourly standalone proxy log outputFrom @arma in #40302:
> as an operator I want to hear about how many connections are open right now. This number might be quite a bit higher than our current stats imply, if some small fraction of connections stay open for many epochs. O...From @arma in #40302:
> as an operator I want to hear about how many connections are open right now. This number might be quite a bit higher than our current stats imply, if some small fraction of connections stay open for many epochs. Or it might not be, I'm not sure.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/15910Figure out what to do with OpenH264 (downloads) in Tor Browser2023-12-13T18:26:54ZGeorg KoppenFigure out what to do with OpenH264 (downloads) in Tor BrowserWe should think about what we want to do with the OpenH264 video codec plugin which Firefox downloads since version 33 shortly after it gets started for the first time (see: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ and h...We should think about what we want to do with the OpenH264 video codec plugin which Firefox downloads since version 33 shortly after it gets started for the first time (see: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ and https://wiki.mozilla.org/QA/WebRTC/OpenH264).
The good news is, the code is free: https://github.com/cisco/openh264. The bad news is it needs to get downloaded from Cisco as a binary blob due to patent issues. And there is currently no known way to build this binary blob deterministically: https://bugzilla.mozilla.org/show_bug.cgi?id=1115874.
I think we should make sure that the plugin does not get downloaded as:
1) It is currently only used for WebRTC which we have disabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1150544#c8) (we should make sure that this argument still holds for ESR 38 when we ship it if that matters)
2) The binary blob is not built reproducibly which poses security risks. Although there seems to be kind of a mechanism for Mozilla to verify things:
```
Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system.
```
3) The download uses essentially Mozilla's "cert pinning". We might want to have something stronger in place.
...
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716 for a way to disable the plugin download.Sponsor 131 - Phase 5 - Ongoing Maintenancerichardrichard2024-01-31https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/10Adapt _getVersionDetails() where needed2023-12-13T15:57:22ZGeorg KoppenAdapt _getVersionDetails() where neededLooking over the `RelayClass` methods `_getVersionDetails()` stood out a bit. It contains:
```
return {
"id": relay.get("version"),
"status": relay.get("versionStatus"),
"recommended": relay.ge...Looking over the `RelayClass` methods `_getVersionDetails()` stood out a bit. It contains:
```
return {
"id": relay.get("version"),
"status": relay.get("versionStatus"),
"recommended": relay.get("recommendedVersion"),
"platform": relay.get("platform"),
}
```
I was wondering why `platform` is a version detail. Maybe we should separate that one out? And then a version is not really an id, in particular as a ton of relays will have the same version. So, maybe we could just replace "id" with "version"?https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/70Configure a task-queue for delegating long-running tasks2023-12-13T15:44:21ZSarthik Guptasarthikg@icloud.comConfigure a task-queue for delegating long-running tasksSarthik Guptasarthikg@icloud.comSarthik Guptasarthikg@icloud.comhttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/69Abstract jobs to be called from the application rather than requiring a syste...2023-12-13T15:44:21ZSarthik Guptasarthikg@icloud.comAbstract jobs to be called from the application rather than requiring a system cronCurrently, onionoo job is exposed an entry point of Tor-Weather project. Calling this job at an interval is configured at the deployment level using system cron or some other tool.
Ideally, the application should internally call the job...Currently, onionoo job is exposed an entry point of Tor-Weather project. Calling this job at an interval is configured at the deployment level using system cron or some other tool.
Ideally, the application should internally call the job at an interval configured from environment variables.Sarthik Guptasarthikg@icloud.comSarthik Guptasarthikg@icloud.comhttps://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/59Onionoo job crash 'NoneType' object is not subscriptable2023-12-13T15:44:20ZGeorg KoppenOnionoo job crash 'NoneType' object is not subscriptableWe got that crash once in our log at 23-03-23-00:15:45. I wonder what crashing here means. Like the whole status update breaks? If so, we should make sure we are a bit more lenient and do not affect everyone in case things go south for o...We got that crash once in our log at 23-03-23-00:15:45. I wonder what crashing here means. Like the whole status update breaks? If so, we should make sure we are a bit more lenient and do not affect everyone in case things go south for one subscription.https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/34Add more details to email2023-12-13T15:44:20ZbauruineAdd more details to emailAt the moment the email only contains the fingerprint. It would be nice to have additional information like the nickname, ip and hostname. And maybe also a link to the relay on metrics.tpo.At the moment the email only contains the fingerprint. It would be nice to have additional information like the nickname, ip and hostname. And maybe also a link to the relay on metrics.tpo.https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/11Clear the emailed flag after we actually have sent the email2023-12-13T15:44:19ZGeorg KoppenClear the emailed flag after we actually have sent the emailLooking at the `node_down` subscription it seems you are clearing the flag to send an email before you actually sent it:
```
# Relay has been down for more than the waiting time
if not self.databas...Looking at the `node_down` subscription it seems you are clearing the flag to send an email before you actually sent it:
```
# Relay has been down for more than the waiting time
if not self.databaseSubscription.emailed:
# Subscriber was not sent an email already
self.databaseSubscription.emailed = True
if self.databaseSubscription.is_active:
# The subscription is active, we should send an email
self.sendEmail()
```
But let's assume there is an error occurring in the `sendEmail()` part that actually prevents the email from getting sent out. I think in that case we should *not* clear out the emailed flag. Rather, what I assume happening in that case is that we a) might want to log an error and b) re-try sending that mail during the next run, and if successful then set `emailed` to `True`.https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/7Do not track Valid flag2023-12-13T15:44:19ZGeorg KoppenDo not track Valid flagThe `Valid` flag is not much used nowadays. Let's just remove everything related to it in the codebase.The `Valid` flag is not much used nowadays. Let's just remove everything related to it in the codebase.https://gitlab.torproject.org/tpo/core/arti/-/issues/1158Do we want an "enabled" option for onion services?2023-12-12T20:08:05ZNick MathewsonDo we want an "enabled" option for onion services?We had the idea of having an "enabled" option on each onion service so you could turn it off without having to remove it from the configuration.
I can add this without too much effort by making it another overlay item in the combined pr...We had the idea of having an "enabled" option on each onion service so you could turn it off without having to remove it from the configuration.
I can add this without too much effort by making it another overlay item in the combined proxy configuration. But do we want to do this at all? We could just tell people to comment out onion services they don't want.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/40013torsocks doesn't work on Mac OS Monterey and higher2023-12-12T18:35:34ZXnDY1torsocks doesn't work on Mac OS Monterey and higherI installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can con...I installed Torsocks 2.3.0 via homebrew, while it could not work properly.
I also compiled torsocks myself with gnu gcc (with 0001-Fix-macros-for-accept4-2.patch). The binary looked good but still didn't working.
By contrast, I can confirm the latest `proxychains-ng` works, looks like new DYLD hooking method for OSX Monterey is required for recent Mac OS (https://github.com/rofl0r/proxychains-ng/commit/4a013fe6a59ed30e045301dc636d07a6ed999081)
There's some relative discuss: https://tor.stackexchange.com/questions/23135/torsocks-doesn-t-torify-on-macos
Can someone take a look?https://gitlab.torproject.org/tpo/core/arti/-/issues/827RPC: Get AF_UNIX terminology right2023-12-12T16:07:20ZNick MathewsonRPC: Get AF_UNIX terminology rightAt and around https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894536 @Diziet asks for correct vocabularity wrt AF_UNIX sockets. This would indeed be a good thing; @Diziet knows how it should go.At and around https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1092#note_2894536 @Diziet asks for correct vocabularity wrt AF_UNIX sockets. This would indeed be a good thing; @Diziet knows how it should go.Arti: RPC SupportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/tpa/status-site/-/issues/39consider embedding cstate in our common web headers2023-12-12T15:04:53Zanarcatconsider embedding cstate in our common web headersSince cstate 5.5.2, we can embed it in other websites magically:
https://github.com/cstate/html-embed
There are two UIs, the dot indicator ([example](https://cstate-embed.pages.dev/dot-indicator)) and a [popup](https://cstate-embed.pag...Since cstate 5.5.2, we can embed it in other websites magically:
https://github.com/cstate/html-embed
There are two UIs, the dot indicator ([example](https://cstate-embed.pages.dev/dot-indicator)) and a [popup](https://cstate-embed.pages.dev/dialog).
I'm not super sure where it would be best to fit this, we don't seem to link to the status page from the main frontpage for starters... maybe it could go in the bottom footer, next to "Contact"?
Maybe the "dot" UI could be used in the common footer, and a popup could be added on support.tpo?
@donuts @kez @lavamind opinions?https://gitlab.torproject.org/tpo/tpa/status-site/-/issues/38fix upstream release tracking2023-12-11T20:46:25Zanarcatfix upstream release trackingIn https://gitlab.torproject.org/tpo/tpa/status-site/-/merge_requests/48, renovate figured out there was something new in the report, and issued a merge request. While that's somewhat useful, it's going to be too noisy for us: we don't w...In https://gitlab.torproject.org/tpo/tpa/status-site/-/merge_requests/48, renovate figured out there was something new in the report, and issued a merge request. While that's somewhat useful, it's going to be too noisy for us: we don't want to upgrade deps every time upstream makes a commit. We want to chase releases.
It's not clear to me how to do this with submodules, so some more research might be required. Another option is to drop renovate here completely and roll our own git checker for tags. Or implement that in renovate ourselves.
For now I've closed !48 so we shouldn't be bugged about that *particular* upgrade, but I think before long we'll have another MR about another upstream commit, so we'll want to figure out a better way soon.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41274chi-node-14 failed to return with IPv4 on reboot2023-12-11T16:25:22Zanarcatchi-node-14 failed to return with IPv4 on reboottonight i rebooted chi-node-14 and it failed to assign itself an IPv4 address.
it seems the trouble as the DAD (Duplicate Address Detection) algo failed to complete correctly:
```
-- Journal begins at Fri 2023-07-07 11:56:06 UTC, ends ...tonight i rebooted chi-node-14 and it failed to assign itself an IPv4 address.
it seems the trouble as the DAD (Duplicate Address Detection) algo failed to complete correctly:
```
-- Journal begins at Fri 2023-07-07 11:56:06 UTC, ends at Fri 2023-07-21 03:13:01 UTC. --
Jul 21 02:33:23 chi-node-14 systemd[1]: Starting Raise network interfaces...
Jul 21 02:33:29 chi-node-14 ifup[4084]: Waiting for DAD... Timed out
Jul 21 02:33:29 chi-node-14 ifup[3903]: ifup: failed to bring up eth0
Jul 21 02:33:29 chi-node-14 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jul 21 02:33:29 chi-node-14 systemd[1]: networking.service: Failed with result 'exit-code'.
Jul 21 02:33:29 chi-node-14 systemd[1]: Failed to start Raise network interfaces.
```
the server was (thankfully!) still reachable over IPv6 so I added a quick hack to the interfaces(5) file:
```
dad-attempts 0
```
... which seems to have fixed the problem in the short term.
in the long term, there are few more questions here:
* why the hell did this fail in the first place?
* is this specific to this site? this server? a misconfiguration on our side or the other?
* is this going to happen again? on another server?
* is it safe to turn DAD off? abolish patriarchy and all, but it's just an acronym dude, chill out?
* is this something that would happen with systemd-networkd as well and do we want to switch already?
a bunch of links i found in my search:
- https://unix.stackexchange.com/questions/192869/why-is-my-dad-slow
- https://www.agwa.name/blog/post/beware_the_ipv6_dad_race_condition
- https://www.the-art-of-web.com/system/ipv6-dad-tentative/
- https://github.com/systemd/systemd/issues/650
- https://serverfault.com/questions/1110760/error-restarting-networking-service
- https://dataplane.org/jtk/blog/2022/12/ipv6dad/
i basically read *none* of those, and only found this and jumped on it:
https://manpages.debian.org/unstable/ifupdown/interfaces.5.en.html#dad-attempts
so maybe further research is needed here...anarcatanarcat