The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-08-23T16:29:53Zhttps://gitlab.torproject.org/tpo/web/manual/-/issues/102[lektor] software latest version macros for documentation to be always updated2021-08-23T16:29:53Zemmapeel[lektor] software latest version macros for documentation to be always updatedWhile writing docs we have some strings that change in each release. Having some sort of macro will help documentation stay updated and the editors will have more time to improve other things.
### Latest versions for software
One nice ...While writing docs we have some strings that change in each release. Having some sort of macro will help documentation stay updated and the editors will have more time to improve other things.
### Latest versions for software
One nice macro should give, in a string, the last Tor Browser version, for example in the string: `tor-browser-linux64-10.0.14_zh-CN.tar.xz` it will be `10.0.14`.
So, we could write 'download Tor Browser i.e. tor-browser-linux64-[!latest_tbb]_zh-CN.tar.xz' or 'Are you using the current Tor Browser ([!latest_tbb])?'.
The most clever thing will be to take this information from the corresponding databags (https://gitweb.torproject.org/project/web/tpo.git/tree/databags/ ) so we dont risk to become outdated, and we dont add more tasks to the release process.https://gitlab.torproject.org/tpo/web/manual/-/issues/103Add Magyar (Hungarian) translation to the Manual2021-09-02T09:41:19ZemmapeelAdd Magyar (Hungarian) translation to the ManualThe Hungarian translation is ready for release (100% translated and 100% reviewed).The Hungarian translation is ready for release (100% translated and 100% reviewed).emmapeelemmapeelhttps://gitlab.torproject.org/tpo/web/team/-/issues/10Consider using forum.tpo for the DocsHackathon2021-08-06T18:59:08ZemmapeelConsider using forum.tpo for the DocsHackathonDuring our DocsHackathons maybe it will be a good idea to test Discourse.
PROS
- It will not be a big number of users
- We can start creating content and testing the system
CONS
- It is on testing
- Before making it public we should ta...During our DocsHackathons maybe it will be a good idea to test Discourse.
PROS
- It will not be a big number of users
- We can start creating content and testing the system
CONS
- It is on testing
- Before making it public we should take a decision because it is currently hosted under torproject.org, and that is only for self-hosted services. We should move it to torproject.net if Discourse people will host it.https://gitlab.torproject.org/tpo/core/arti/-/issues/157Use derive_builder in tor-dirmgr::config2021-09-09T15:21:53ZNick MathewsonUse derive_builder in tor-dirmgr::configWe have a bunch of builder types in `tor_dirmgr::config`, which would be simpler if they eventually used `derive_buidler` instead.
We probably **should not** do this right away: instead we should get more experience with our configurati...We have a bunch of builder types in `tor_dirmgr::config`, which would be simpler if they eventually used `derive_buidler` instead.
We probably **should not** do this right away: instead we should get more experience with our configuration ergonomics first, by writing a bunch of sample code getting a bunch of feedback.https://gitlab.torproject.org/tpo/core/tor/-/issues/40445tor_tls_finish_handshake warning spamming logs during relay operation2022-07-07T00:47:11Zharpiator_tls_finish_handshake warning spamming logs during relay operation### Summary
The following message is rapidly filling my notice-level logs during the Tor middle relay operation:
```
[warn] tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake didn't get set. Fixing that. (on Tor 0.4.5.9 )
``...### Summary
The following message is rapidly filling my notice-level logs during the Tor middle relay operation:
```
[warn] tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake didn't get set. Fixing that. (on Tor 0.4.5.9 )
```
The log file is growing fast. I've sent a bug report to OpenBSD via email, but I'm not sure they received it - no response so far. That's why I brought it here. Maybe it's reproducible upstream too.
### Steps to reproduce:
1. Install the tor package with "pkg_add tor"
2. Edit /etc/tor/torrc as in this gist: https://gist.github.com/o-alquimista/ba5b1043cb1be05eb76e0dd7831bf44d
3. Start tor service
The tor service may fail to start due to "permission denied" when writing the notice log file. I had to manually create the /var/log/tor directory and set its ownership to the "_tor" user.
4. Watch the notices.log file. In spite of the warnings, the relay runs without any noticeable problems. You can see it here: https://metrics.torproject.org/rs.html#details/3FA93D41E9A7C4C47B77C0D7F617999B6D5D0B62
### Environment
- Tor 0.4.5.9
- OpenBSD 6.9 arm64 (-stable)
- The device is a Raspberry Pi 4 Model B Rev 1.2
- Installation method is pkg_add (OpenBSD package)Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/205Consider leaning into the reactor pattern more, instead of using mutexes2021-11-12T15:25:10ZetaConsider leaning into the reactor pattern more, instead of using mutexesUsing `Mutex`es too much can be a bit of an antipattern: it introduces the possibility of deadlocks, it can interact poorly with `await` boundaries (see #181 too), and it can make the code a bit harder to reason about, especially when mu...Using `Mutex`es too much can be a bit of an antipattern: it introduces the possibility of deadlocks, it can interact poorly with `await` boundaries (see #181 too), and it can make the code a bit harder to reason about, especially when multiple locks are involved.
Some code that uses mutexes (like `ClientCirc` in `tor-proto`) uses it to share state with a separate "reactor" task. It might make more sense to make more use of that reactor (by extending the existing message-passing code), instead of having to use a mutex to share state in this way.
(There's probably more than just that example, as well!)Arti 0.1.0 release: Okay for experimental embeddingetaetahttps://gitlab.torproject.org/tpo/core/arti/-/issues/183Avoid same-family bugs with guards, and chosen exits2021-12-07T16:01:30ZNick MathewsonAvoid same-family bugs with guards, and chosen exitsWhen a chosen exit is given, and guards are currently in use Arti may currently build paths where the guard shares a family with the exit. This happens because of a limitation in the way that GuardRestriction is implemented: we can't lo...When a chosen exit is given, and guards are currently in use Arti may currently build paths where the guard shares a family with the exit. This happens because of a limitation in the way that GuardRestriction is implemented: we can't look at the family of the provided exit, because we don't have access to a NetDir when we're checking that restriction later on.
Some possible implementations here include:
* putting a hashset containing the entire family into the GuardRestriction.
* somehow giving the `GuardMgr::expire_and_answer_pending_requests()` code access to a NetDir. (See #161)Arti 0.1.0 release: Okay for experimental embeddingNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40582Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide2021-09-03T17:30:19ZMattiLinnanvuoriTor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide### Summary
[tor.dump.gz](/uploads/010c4c20278bfdc4c637d5e58e2d7593/tor.dump.gz)
Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide on HP EliteBook 8730w
### Steps to reproduce
1. cd Download/tor-browser_en-US
2. ./start-tor-b...### Summary
[tor.dump.gz](/uploads/010c4c20278bfdc4c637d5e58e2d7593/tor.dump.gz)
Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide on HP EliteBook 8730w
### Steps to reproduce
1. cd Download/tor-browser_en-US
2. ./start-tor-browser.desktop
### What is the current bug behavior?
Tor Browser 10.5.2 tabs always crash on Fedora Xfce Rawhide.
### What is the expected behavior?
Tor Browser 10.5.2 tabs do not crash on Fedora Xfce Rawhide.
### Environment
Fedora Xfce Rawhide
Distribution package tor-browser-linux64-10.5.2_en-US.tar.xz
### Relevant logs and/or screenshots
Core was generated by `/home/mattilinnanvuori/Downloads/tor-browser_en-US/Browser/firefox.real -conten'.
Program terminated with signal SIGSYS, Bad system call.
#0 clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:62https://gitlab.torproject.org/tpo/core/arti/-/issues/211Do we close connections at the right times?2022-07-07T15:22:20ZNick MathewsonDo we close connections at the right times?Tor has a longstanding protocol issue where we don't support "half-open" connections: a stream isn't torn down unless it is actually closed, and shutdown(2) doesn't actually do anything.
But that aside, we may have issues in Arti where...Tor has a longstanding protocol issue where we don't support "half-open" connections: a stream isn't torn down unless it is actually closed, and shutdown(2) doesn't actually do anything.
But that aside, we may have issues in Arti where we don't close things at the right time. @trinity-1686a hit one of these in !90, and it seems that @eta might be hitting another while working on example code. I don't know whether the issues that they've hit are caused by the lonstanding Tor protocol problem above, or whether they are a separate bug in Arti that we need to fix.
See also #190 for a possibly related issue.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40583Documentation on how to customize .tor-browser2022-07-08T23:34:10ZpabloDocumentation on how to customize .tor-browserThe Tor Browser bundle stores most of it's configuration in `~/.tor-browser`. I'd like to know if this directory is customizable. Can I change it by setting an environment variable or something? I'm asking because I want to document this...The Tor Browser bundle stores most of it's configuration in `~/.tor-browser`. I'd like to know if this directory is customizable. Can I change it by setting an environment variable or something? I'm asking because I want to document this in <https://wiki.archlinux.org/title/XDG_Base_Directory>.https://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40024Remove check for dizum's old address2021-08-12T07:55:04ZGeorg KoppenRemove check for dizum's old addressIn https://gitlab.torproject.org/tpo/core/tor/-/issues/31406 we implemented a check to make sure dizum's old IP address is still reachable. We don't need that check anymore as the IP address is going away/gone.In https://gitlab.torproject.org/tpo/core/tor/-/issues/31406 we implemented a check to make sure dizum's old IP address is still reachable. We don't need that check anymore as the IP address is going away/gone.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/40008Process overload-general descriptor line2021-09-06T18:07:52ZHiroProcess overload-general descriptor lineAs part of https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40005 we want to expose an overload flag on relay-search so that relay operators know when their relay is experiencing an "overloaded state".
Whil...As part of https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40005 we want to expose an overload flag on relay-search so that relay operators know when their relay is experiencing an "overloaded state".
While metrics-lib is already exposing overload-ratelimits and overload-fd-exhausted flags, these are both in the extrainfo descriptor. Processing these lines in onionoo needs a little bit of planning to bump more memory to the onionoo machines.
As discussed in https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/merge_requests/2#note_2746623 this change can happen in 2 moments.
First we expose the overload-general line from the server descriptor [1] to add a boolean attribute that will alert operators that their relay is in an overloaded state
Then we plan a memory boost to the onionoo machines or a better update strategy for the details document and deploy the change discussed in https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/merge_requests/2
[1] https://github.com/torproject/torspec/blob/main/dir-spec.txt#L638HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40352Onboard new fundraising Coordinator2021-08-10T15:25:36ZGabagaba@torproject.orgOnboard new fundraising Coordinator
- [x] [Civi](https://gitlab.torproject.org/tpo/tpa/repos/-/issues/1)
- [x] NextCloud with access to Grants and TPI groups
- [x] new user in BBB
- [x] new user in GitLab with access to organization group
- [x] new user in RT
- [x] add hi...
- [x] [Civi](https://gitlab.torproject.org/tpo/tpa/repos/-/issues/1)
- [x] NextCloud with access to Grants and TPI groups
- [x] new user in BBB
- [x] new user in GitLab with access to organization group
- [x] new user in RT
- [x] add him to grants@torproject.org
- [x] be sure he is subscribed to tor-internal@Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40585Rebase 11.0 patches onto 78.13.0esr2021-08-10T19:19:02ZMatthew FinkelRebase 11.0 patches onto 78.13.0esr32b735c6048b6130aec946985cd8f6fab02bf20032b735c6048b6130aec946985cd8f6fab02bf200https://gitlab.torproject.org/tpo/applications/android-components/-/issues/40066Rebase 11.0 patches onto 91.0.122021-08-10T14:40:52ZMatthew FinkelRebase 11.0 patches onto 91.0.121d401758fb29294099f9f155f3db4e15e9a712ec1d401758fb29294099f9f155f3db4e15e9a712echttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40348Prep 11.0a42021-08-10T22:24:26ZMatthew FinkelPrep 11.0a4https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40021json state-of-censorship should include Snowflake lines2022-03-24T09:54:34ZRoger Dingledinejson state-of-censorship should include Snowflake linesCurrently https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json has no mention of Snowflake. We should fix that! :)Currently https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship/-/blob/main/state-of-censorship.json has no mention of Snowflake. We should fix that! :)Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40022bridgetest: make output format more robust2022-03-01T15:57:24ZRoger Dingledinebridgetest: make output format more robustHere's the preliminary data format for the logs that come out of the bridgetest docker image: <br>
https://gitlab.torproject.org/cohosh/probetest#data-format
and there are some scripts like <br>
https://gitlab.torproject.org/cohosh/prob...Here's the preliminary data format for the logs that come out of the bridgetest docker image: <br>
https://gitlab.torproject.org/cohosh/probetest#data-format
and there are some scripts like <br>
https://gitlab.torproject.org/cohosh/probetest/-/blob/main/analysis/makecsv <br>
that help to generate the csv format.
We should look through peer formats, like OONI's data format and censored planet, and get ideas for what else we'll wish we'd included.
For examples:
* timestamp of when the test happened (perhaps rounded to something granular)
* which version of the test generated this entry
* more detail about the test target, e.g. the hashed fingerprint of the bridge that we tested.
* time spent from start of test until result (I realized this one after looking at the various aborted tests from China, where if we knew how long the successful tests took, and found that they were already bumping up against our timeout, that would be useful to know.)
* (maybe, I'm not sure, we should ask others for advice) All of the stuff that's implicit in the filename and directory structure, so it's in the file too -- which country we're testing from, AS we map to, the name of the test, etc.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/40020FF91 network audit2021-12-17T15:24:44ZMatthew FinkelFF91 network audithttps://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40025Unable to retrieve extrainfo descriptors2021-08-25T13:34:47ZGeorg KoppenUnable to retrieve extrainfo descriptorsStarting 08/09/2021 08:35:00 UTC I've been getting an exception every hour similar to:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 08/09/2021 08:35
error: write-history...Starting 08/09/2021 08:35:00 UTC I've been getting an exception every hour similar to:
```
Unable to retrieve the present extrainfo descriptors...
source: http://171.25.193.9:443/tor/extra/all
time: 08/09/2021 08:35
error: write-history line has non-numeric values: write-history 2021-08-08 18:08:39 (86400 s) 649198592,
```
which is quite puzzling. Why do we get that Stem exception now?
/cc @dgoulet