The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-11T17:14:29Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1057migrate from trust-dns to hickory2024-03-11T17:14:29Ztrinity-1686amigrate from trust-dns to hickorytrust-dns will soon get rebranded to Hicktory (this is not a change of ownership, just rebranding). We should migrate from one to the other to keep getting updates.
[public announcement](https://bluejekyll.github.io/blog/posts/announcin...trust-dns will soon get rebranded to Hicktory (this is not a change of ownership, just rebranding). We should migrate from one to the other to keep getting updates.
[public announcement](https://bluejekyll.github.io/blog/posts/announcing-hickory-dns/)https://gitlab.torproject.org/tpo/community/l10n/-/issues/40119Update torlauncher translation setup2024-01-31T14:43:58ZemmapeelUpdate torlauncher translation setupTorlauncher's setup needs to be updated. The repository is now https://gitlab.torproject.org/tpo/applications/torbrowser-launcher and we need to add it to weblate.
We also need to know if we still need this other tor-launcher branches: ...Torlauncher's setup needs to be updated. The repository is now https://gitlab.torproject.org/tpo/applications/torbrowser-launcher and we need to add it to weblate.
We also need to know if we still need this other tor-launcher branches: https://gitlab.torproject.org/tpo/translation/-/branches?state=all&sort=updated_asc&search=launcher and if not, move them to the attic.emmapeelemmapeelhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42145System tor users won't be notified if the connection to the control port fails2023-10-11T21:15:41ZPier Angelo VendrameSystem tor users won't be notified if the connection to the control port failsIn #42129 we removed the "restart Tor" prompt when the browser doesn't start the Tor process.
In !812 we're adding a warning to use check.tpo in that case, which is independent from the control port connection.
A case remains uncovered...In #42129 we removed the "restart Tor" prompt when the browser doesn't start the Tor process.
In !812 we're adding a warning to use check.tpo in that case, which is independent from the control port connection.
A case remains uncovered: a user set the address of their system tor correctly, but they haven't set the proper settings for the control port.
An idea is adding another blocking prompt, just like the restart Tor one, but with another message (basically: "We couldn't connect to the control port. Please check your settings. Your proxy settings might be still valid, but you won't have the circuit display") and just the "OK" button (we can't do anything in that case).
However, some users might get annoyed by this, but I don't like the idea of adding a checkbox to ignore this error.
Another idea could be a non-blocking notification, like the one for the language.https://gitlab.torproject.org/tpo/community/outreach/-/issues/40047Tor activities at FOSDEM 20242024-02-22T23:05:34ZRoger DingledineTor activities at FOSDEM 2024FOSDEM 2024 has been announced, and it is scheduled for Brussels, Feb 2-4. <br>
https://fosdem.org/2024/news/
They have published a call-for-stands, where by 'stand' they mean 'booth'.
And today they published a call-for-devrooms -- ho...FOSDEM 2024 has been announced, and it is scheduled for Brussels, Feb 2-4. <br>
https://fosdem.org/2024/news/
They have published a call-for-stands, where by 'stand' they mean 'booth'.
And today they published a call-for-devrooms -- hopefully there will be a privacy devroom, but I'm assuming we don't want to lead that process.
The call for presentations does not yet seem to be out.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40969Improve authenticode-timestamping.sh for when timestamping fails2024-03-20T16:47:09ZboklmImprove authenticode-timestamping.sh for when timestamping failsWhen timestamping fails (for example because of temporary error connecting to http://timestamp.digicert.com), restarting this step fails because the tmp directory `"$signed_dir/$tbb_version/tmp-timestamp"` already exists.
We can replace...When timestamping fails (for example because of temporary error connecting to http://timestamp.digicert.com), restarting this step fails because the tmp directory `"$signed_dir/$tbb_version/tmp-timestamp"` already exists.
We can replace this directory with some temporary directory created with `mktemp -d`.boklmboklmhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42137Review UX of "Tor Browser Support" link in about:preferences.2023-09-29T19:59:27ZhenryReview UX of "Tor Browser Support" link in about:preferences.Copied from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910#note_2941435
Currently, we have one link in "about:preferences" shown as
```
{ -brand-short-name } Support
```
in the bottom left corner of "about:p...Copied from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910#note_2941435
Currently, we have one link in "about:preferences" shown as
```
{ -brand-short-name } Support
```
in the bottom left corner of "about:preferences". I.e. "Firefox Support" and "Tor Browser Support".
In firefox, the link goes to https://support.mozilla.org/en-US/kb/firefox-options-preferences-and-settings. I.e. SUMO page for "about:preferences".
In tor browser, the link goes to https://support.torproject.org/tbb/. I.e. the tor browser FAQs. See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32092.
In mullvad browser, the link goes to https://mullvad.net/en/help/tag/mullvad-browser/. See https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/177.
In addition, there is another link in "about:preferences" that goes to the same page for firefox, shown when you have an empty search result as
```
Sorry! There are no results in Settings for “some search term”.
Need help? Visit <a>{ -brand-short-name } Support</a>
```
However, I'm not sure `https://support.torproject.org/tbb/` is the best redirect for these contexts. I feel like the initial decisions in the linked issues were responding to the wording "Tor Browser Support" rather than the surrounding context or the original firefox SUMO page. In particular:
1. The tor project page doesn't help with understanding "about:preferences" like firefox does. Same applies to mullvad.
2. Depending on what the user is doing, or if they haven't bootstrapped yet, "about:manual" might be more useful.
So I wonder if it might make more sense to just design something more specific that works for tor browser (and mullvad browser), rather than just hijacking an existing firefox link.
/cc @donuts for some UX inputhttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/26Keep tags across family members in sync2024-01-16T13:50:05ZGeorg KoppenKeep tags across family members in syncWe got families included in our tagging process in #20, but we should make sure that the families stay in sync tag-wise. That is: between different tagging sessions family members might not be the same. If the family loses members then t...We got families included in our tagging process in #20, but we should make sure that the families stay in sync tag-wise. That is: between different tagging sessions family members might not be the same. If the family loses members then that's not a big deal. However, newly added relays should have all the tags their other family members have once I resume tagging relays at a later time.TagTor is completed for its scope in Sponsor 112https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42136Consider stripping `utm` parameters from mozilla links.2023-09-28T17:16:36ZhenryConsider stripping `utm` parameters from mozilla links.Split from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910
Currently some mozilla links within base browser add some parameters to the url: "utm_source", "utm_medium" and "utm_content". See https://searchfox.or...Split from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910
Currently some mozilla links within base browser add some parameters to the url: "utm_source", "utm_medium" and "utm_content". See https://searchfox.org/mozilla-esr115/search?q=utm_content&path=&case=false®exp=false
In particular, this came up in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910 because `moz-support-link` has a [mechanism to add these](https://searchfox.org/mozilla-esr115/rev/853578e651edd1a6be0400e9124ae735d8e7213c/toolkit/content/widgets/moz-support-link/moz-support-link.mjs#91,107-125).
A lot of these links are outside the tor browser UI (e.g. newtab and pocket). The only exceptions I found were in "about:addons", like the search url and the recommended badge link.
/cc @richard @pierovhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1050Calculate the worst_case_end time for desc publication attempts2023-10-04T18:02:15Zgabi-250Calculate the worst_case_end time for desc publication attemptsCalculate the `worst_case_end` (the time the publication attempt will definitely be complete or abandoned) and pass call `IptSet::note_publication_attempt` in the publisher.Calculate the `worst_case_end` (the time the publication attempt will definitely be complete or abandoned) and pass call `IptSet::note_publication_attempt` in the publisher.gabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1049Start a protocol name registry with our custom ssh algorithm names2023-11-15T19:39:50Zgabi-250Start a protocol name registry with our custom ssh algorithm namesStart a protocol name registry in the torspec repo and document the usage and purpose of the following "protocol" names:
```
+----------------------------------+--------------------+---------------------+------------------------+
| ...Start a protocol name registry in the torspec repo and document the usage and purpose of the following "protocol" names:
```
+----------------------------------+--------------------+---------------------+------------------------+
| Public Key Algorithm Name | Public Key Format | Private Key Format | Purpose |
|----------------------------------|--------------------|---------------------|------------------------|
| x25519@torproject.org | [TODO link to spec | [TODO link to spec | Arti keystore storage |
| | describing the key | describing the key | format |
| | format] | format] | |
|----------------------------------|--------------------|---------------------|------------------------|
| ed25519-expanded@torproject.org | [TODO link to spec | [TODO link to spec | Arti keystore storage |
| | describing the key | describing the key | format |
| | format] | format] | |
| | | | |
+----------------------------------+--------------------+---------------------+------------------------+
```Arti: Onion service supportIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40964Create new Tor Browser gpg subkey2023-10-16T21:20:23ZboklmCreate new Tor Browser gpg subkeyAfter being extended by 5 months in #40957, the current Tor Browser gpg subkey will be expiring in some months. We should generate a new subkey and switch to it while the old one is still valid for a few months.After being extended by 5 months in #40957, the current Tor Browser gpg subkey will be expiring in some months. We should generate a new subkey and switch to it while the old one is still valid for a few months.boklmboklm2023-11-13https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40290standalone snowflake README still says go 1.15+ needed2023-10-20T15:25:32ZRoger Dingledinestandalone snowflake README still says go 1.15+ neededThe proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two t...The proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two things:
* We should update the README to reflect current requirements
and
* We should figure out what we want to tell people on Debian, who can no longer build snowflake, if they don't want to engage in installing and maintaining the whole toolchain manually. Do they stick with v2.6.1? Do they turn off their snowflake? Something even smarter? ...and then write that in the README too.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/42117Tor Bootstrap Log on Android becomes small2023-09-27T21:31:12ZPier Angelo VendrameTor Bootstrap Log on Android becomes smallI'm not sure of the STR, I think swiping left and right could help.
<details><summary>Screenshot</summary>
![Screenshot_20230920-173414](/uploads/5a11ba7505f431aa12c0d4bbee989b7e/Screenshot_20230920-173414.png)
</details>I'm not sure of the STR, I think swiping left and right could help.
<details><summary>Screenshot</summary>
![Screenshot_20230920-173414](/uploads/5a11ba7505f431aa12c0d4bbee989b7e/Screenshot_20230920-173414.png)
</details>https://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/25Add filtering options for relays one is interested in2024-01-16T13:50:05ZGeorg KoppenAdd filtering options for relays one is interested inFor bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.For bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.TagTor is completed for its scope in Sponsor 112https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42116Possible confusion between search engine mismatch in URL bar and settings?2023-12-01T19:32:13ZJag TalonPossible confusion between search engine mismatch in URL bar and settings?In 13.0a4, there seems to be a mismatch between the search engines in the search bar (I believe called search shortcuts) and the default search engine setting. I'm wondering:
- Will people lose their default search engine on upgrade? I ...In 13.0a4, there seems to be a mismatch between the search engines in the search bar (I believe called search shortcuts) and the default search engine setting. I'm wondering:
- Will people lose their default search engine on upgrade? I personally use DuckDuckGoOnion, so I'm wondering now that it moved to the search shortcuts will it stop being the default?
- Should it be moved to search shortcuts completely or just be duplicated? I feel like the discrepancy creates confusion (at least it did for me!) cc @donuts
Apologies if this has been discussed before!
<details><summary>Screenshots of the pages</summary>
![signal-2023-09-20-083453_003](/uploads/734a3e9bdf526973b695330a17a7aa3f/signal-2023-09-20-083453_003.png)
![signal-2023-09-20-083453_002](/uploads/978d090a4b140fd5afe1ab904864b958/signal-2023-09-20-083453_002.png)
</details>https://gitlab.torproject.org/tpo/core/arti/-/issues/1040tor-guardmgr wakes arti up every second!2023-11-15T19:00:53ZNick Mathewsontor-guardmgr wakes arti up every second!See https://gitlab.torproject.org/tpo/core/arti/-/issues/1040#note_2950549
I think this is rather poor. People have spent a lot of effort abolishing high-frequency periodic wakeups, because they waste energy (battery). And apparently,...See https://gitlab.torproject.org/tpo/core/arti/-/issues/1040#note_2950549
I think this is rather poor. People have spent a lot of effort abolishing high-frequency periodic wakeups, because they waste energy (battery). And apparently, the work done is sufficiently extensive to make a test unreasonably slow.
(The test `tor_hsclient::state::test::expiry` is using a "giant leap" clock update because otherwise it has to similate every one of these wakeups.
Perhaps `tor_hsservice::timeout_track` could help.
### Old description
cc @gabi-250
Not a huge issue, but state::test::expiry now takes longer to run than any other test in Arti. Perhaps worth fixing if it's easy to do so?
(Found because I use `cargo-nextest`, which runs everything in parallel and displays the times.)Arti: Feature parity with the C implementationIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40861Look into build failures on modern Debian for CI on main2024-03-20T14:33:46ZAlexander Færøyahf@torproject.orgLook into build failures on modern Debian for CI on main@weasel reported a build issue on i386 with test failures. Have a look at:
```
180923 19:04:59 + weasel: sandbox/openat_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/opendir_dirname: [forking]
180923 19:05:00 + ...@weasel reported a build issue on i386 with test failures. Have a look at:
```
180923 19:04:59 + weasel: sandbox/openat_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/opendir_dirname: [forking]
180923 19:05:00 + weasel: FAIL ../src/test/test_sandbox.c:266: opendir: Operation not permitted [1]
180923 19:05:00 + weasel: [opendir_dirname FAILED]
180923 19:05:00 + weasel: sandbox/chmod_filename: [forking] OK
180923 19:05:00 + weasel: sandbox/chown_filename: [forking] OK
180923 19:05:02 + weasel: hm.
180923 19:05:17 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367821
180923 19:05:59 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367812
180923 19:06:00 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367811
180923 19:06:04 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/367808
180923 19:06:06 + weasel: they all do that
180923 19:06:35 trinity-1686: maybe related to core/tor!446 ?
180923 19:06:35 -tor:#tor-dev- https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/446 - Fix sandbox on AArch64, RISC-V
180923 19:06:53 + weasel: i386
chat and mess w it
180923 19:09:48 + ahf: weasel: it's only impacting 0.4.9, right?
180923 19:09:56 + ahf: as in, main - not your 0.4.8 builds
180923 19:10:44 + weasel: maybe
180923 19:11:14 + weasel: if that's likely, then I'll push the signed tag and see how those go
180923 19:11:43 + ahf: 0.4.9 is main, so things can break there a bit more frequently than it should on any of the release-* branches
180923 19:12:34 + weasel: pushed the tag, let's see how that pipeline goes
180923 19:12:43 + ahf: oki, let us know how it goes!
180923 19:13:04 + weasel: https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines/104953 you can know as soon as I know :)
180923 19:13:34 + ahf: i am not going to monitor a build log for a hopeful success here - i am deep into other things in parallel
180923 19:41:39 + ahf: ../src/test/test_bt_cl.c: In function 'crash':
180923 19:41:40 + ahf: ../src/test/test_bt_cl.c:46:24: warning: null pointer dereference [-Wnull-dereference] 46 | *(volatile int *)0 = 0;
180923 19:41:43 + ahf: it's not wrong
180923 20:01:27 + weasel: 0.4.8 did build
180923 20:03:55 + ahf: so 0.4.9 has some build issue on ... all your debian's?
180923 20:06:57 + weasel: just i386 on more modern ones
180923 20:09:45 + ahf: so i386 on modern debian?
180923 20:09:55 + ahf: thank you, weasel
180923 20:09:59 + ahf: creating a ticket
```Tor: 0.4.8.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/13Upload the container to our registry2024-03-03T14:07:46Zmicahmicah@torproject.orgUpload the container to our registryRight now, the only place you can pull the built container is from dockerhub. Now that Tor's gitlab has the container registry enabled, we should be building and pushing the container to our registry and consider that the main place we a...Right now, the only place you can pull the built container is from dockerhub. Now that Tor's gitlab has the container registry enabled, we should be building and pushing the container to our registry and consider that the main place we ask people to pull from.
This can be integrated into the CI relatively easily, and I've got some example for that, if it would be helpful!meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1039netdoc: Sort introduction points before encoding2023-10-16T15:21:00ZNick Mathewsonnetdoc: Sort introduction points before encodingWe should ensure that our introduction points are sorted in some order before we encode them, so that we do not leak information about when we added them to our list of introduction points.
I don't think that this is specified in rend-s...We should ensure that our introduction points are sorted in some order before we encode them, so that we do not leak information about when we added them to our list of introduction points.
I don't think that this is specified in rend-spec or done by C tor (cc @dgoulet), but it's probably a good security feature to add in both of those places too.