The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-05T15:48:14Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/26404Fixup commits for unused symbols2023-01-05T15:48:14ZMatthew FinkelFixup commits for unused symbolsSome Tor Browser patches result in unreachable and/or unused code. This isn't a problem, in general, but when Firefox is built with `-Werror`, this causes a compile-time build failure. I'd like to fix these failures in our tree so we can...Some Tor Browser patches result in unreachable and/or unused code. This isn't a problem, in general, but when Firefox is built with `-Werror`, this causes a compile-time build failure. I'd like to fix these failures in our tree so we can begin pushing Try builds for our entire patchset.
This is step 0 on the larger/grander path of running the entire Firefox test suite against Tor Browser. Currently, too many unit tests fail when run on Tor Browser's patches, so this will not be useful (by itself) right now.
To be clear, I'm not sure if we should patch every unit test failure or if we should write a script that fetches the results and tells us if any failures were not expected - but this is a different topic.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/21Control spec is ambiguous whether a GETCONF error message is specified2022-02-21T19:13:04ZdmrControl spec is ambiguous whether a GETCONF error message is specifiedThe [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
...The [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
"552 unknown configuration keyword" message.
```
The spec also has a [[about error messages](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n1809|clause)]:
```
Unless specified to have specific contents, the human-readable messages
in error replies should not be relied upon to match those in this document.
```
Unfortunately, it's unclear what //specified to have specific contents// means here. The message for `GETCONF` is quoted, which at least in cursory read made me think it was //specified//.
But I suppose it's ambiguous.
==== Expected change
In discussion over IRC, arma suggested it...
> might be even better to change the spec to be like "replies with a 552 message because of the unrecognized configuration key."
Overall, it was agreed upon amongst arma, meejah, sysrqb, and myself that the spec shouldn't be denoting a specific message here, and that controllers shouldn't rely on a specific message. Only the numeric code `552` should be relied upon.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25872When Clicking more information when visiting a V3 onion some of the buttons a...2022-11-30T16:39:10ZTracWhen Clicking more information when visiting a V3 onion some of the buttons are cut offWhen Clicking more information when visiting a V3 onion some of the buttons are cut off.
1. go to http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion
2. click the "!" next to the URL and click ">" then click more inform...When Clicking more information when visiting a V3 onion some of the buttons are cut off.
1. go to http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion
2. click the "!" next to the URL and click ">" then click more information.
3.The "View cookies" and "View saved passwords" buttons are cut off.
I attached a photo showing the buttons cut off.
Tor Browser 7.5.3
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/25863Check where the -mwindows flag is needed2023-01-05T12:42:49ZboklmCheck where the -mwindows flag is neededCurrently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really nee...Currently we are setting the `-mwindows` flag by default in `CFLAGS` and `LDFLAGS` defined in `rbm.conf`, which are currently used (through `var/configure_opt`) in tor, gmp, libevent and go.
We should check where this flag is really needed, and only set it there.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/25416[warn] Received http status code 404 ("Consensus is too old") from server '19...2022-06-16T15:31:48Ztoralf[warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, strat...the local time is ok :
```
date -u
Sat Mar 3 16:18:01 UTC 2018
cat </dev/tcp/time.nist.gov/13
ntpdate -q 2.de.pool.ntp.org
server 2a01:4f8:172:326b::2, stratum 2, offset -0.000140, delay 0.02594
server 2a01:4f8:221:3b02::101:1, stratum 2, offset -0.000601, delay 0.02594
server 2a01:238:439c:1900::3:1, stratum 2, offset 0.000477, delay 0.04520
server 2a02:16d0:0:4::4, stratum 2, offset -0.002245, delay 0.03976
server 90.187.7.5, stratum 2, offset -0.002271, delay 0.04788
server 129.70.132.36, stratum 2, offset 0.002152, delay 0.04262
server 145.239.3.131, stratum 2, offset 0.001487, delay 0.03177
server 85.236.36.4, stratum 2, offset -0.000501, delay 0.03650
3 Mar 17:18:09 ntpdate[18195]: adjust time server 2a01:4f8:221:3b02::101:1 offset -0.000601 sec
```
And I still get once a day or so _:
```
Mar 03 17:18:01.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
Mar 03 17:18:01.000 [notice] Tor 0.3.4.0-alpha-dev (git-efc105716283bbdf) opening log file.
Mar 03 17:18:02.000 [warn] Received http status code 404 ("Consensus is too old") from server '194.109.206.212:80' while fetching consensus directory.
```
tor version is 0.3.4-alpha-devhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24950"Restrict third party cookies and other tracking data" enabled = disables exc...2022-11-29T14:24:57ZTrac"Restrict third party cookies and other tracking data" enabled = disables exceptions list for popupsOptions -> Privacy -> Restrict third party cookies and other tracking data
When enabled, popup blocker ignores exceptions list and blocks popups from all websites.
**Trac**:
**Username**: vanowmOptions -> Privacy -> Restrict third party cookies and other tracking data
When enabled, popup blocker ignores exceptions list and blocks popups from all websites.
**Trac**:
**Username**: vanowmSponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23660Handle exceptions in content sandboxing code for Tor Browser on Windows properly2022-11-30T14:58:29ZGeorg KoppenHandle exceptions in content sandboxing code for Tor Browser on Windows properlyAt the moment we just rip out the SEH parts of the content sandboxing code as mingw-w64 has trouble handling it. We should provide a proper fix for it, though.At the moment we just rip out the SEH parts of the content sandboxing code as mingw-w64 has trouble handling it. We should provide a proper fix for it, though.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23263Rip out startup GfxSanityTest entirely2022-11-30T16:50:26ZcypherpunksRip out startup GfxSanityTest entirelyMozilla understood it's a Windows-only "feature" in FF54 https://bugzilla.mozilla.org/show_bug.cgi?id=1339432, but Tor Browser doesn't need that trash.Mozilla understood it's a Windows-only "feature" in FF54 https://bugzilla.mozilla.org/show_bug.cgi?id=1339432, but Tor Browser doesn't need that trash.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/23168Guard sample calls relay descriptors a "consensus"2022-02-07T19:39:17ZteorGuard sample calls relay descriptors a "consensus"[info] router_load_routers_from_string: 96 elements to add
[info] sampled_guards_update_from_consensus: Updating sampled guard status based on received consensus.
The message should either say "received directory document(s)", or actual...[info] router_load_routers_from_string: 96 elements to add
[info] sampled_guards_update_from_consensus: Updating sampled guard status based on received consensus.
The message should either say "received directory document(s)", or actually describe the directory document it just received.https://gitlab.torproject.org/tpo/core/torspec/-/issues/83Padding, Keepalive and Drop cells should have random payloads2022-03-17T19:41:21ZteorPadding, Keepalive and Drop cells should have random payloadstor-spec says:
```
Link padding can be created by sending PADDING or VPADDING cells
along the connection; relay cells of type "DROP" can be used for
long-range padding. The contents of a PADDING, VPADDING, or DROP
cell SHOUL...tor-spec says:
```
Link padding can be created by sending PADDING or VPADDING cells
along the connection; relay cells of type "DROP" can be used for
long-range padding. The contents of a PADDING, VPADDING, or DROP
cell SHOULD be chosen randomly, and MUST be ignored.
```
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1534
But padding cells sent by channelpadding_send_padding_cell_for_callback() and keepalive cells sent by run_connection_housekeeping() have a payload of all zero bytes.
I don't know if this is a security issue or not. It is probably ok, unless Tor has compression enabled on its TLS connections. If compression is enabled, all the padding data size calculations will be wrong.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22633Running ./start-tor-browser.desktop --detach --log creates two log files2022-08-03T14:52:38ZGeorg KoppenRunning ./start-tor-browser.desktop --detach --log creates two log filesAdding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://bl...Adding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://blog.torproject.org/comment/269202#comment-269157.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22584More RWX memory pages for TBB on some Windows versions2022-11-30T16:58:09ZArthur EdelsteinMore RWX memory pages for TBB on some Windows versionsA cypherpunk has reported some RWX memory pages were observed for Tor Browser on Windows 7 and Windows 10. See:
* ticket:21617#comment:4
* ticket:21617#comment:7
* ticket:21617#comment:14A cypherpunk has reported some RWX memory pages were observed for Tor Browser on Windows 7 and Windows 10. See:
* ticket:21617#comment:4
* ticket:21617#comment:7
* ticket:21617#comment:14Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/22449Remove timestamp_dirty kludge from mark_circuit_unusable_for_new_conns()2021-09-16T14:18:43ZNick MathewsonRemove timestamp_dirty kludge from mark_circuit_unusable_for_new_conns()In mark_circuit_unsusable_for_new_conns(), we set the unusable_for_new_conns flag... but we also carry around some old code that messes around with timestamp_dirty.
The root problem here is that the old code makes timestamp_dirty into...In mark_circuit_unsusable_for_new_conns(), we set the unusable_for_new_conns flag... but we also carry around some old code that messes around with timestamp_dirty.
The root problem here is that the old code makes timestamp_dirty into a lie; "unusable" and "dirty" are not the same concept.
We should carefully audit timestamp_dirty and its users to make sure that it's safe to remove this old kludge, and then remove it or replace it with something more accurate.https://gitlab.torproject.org/tpo/core/chutney/-/issues/22360chutney's --quiet mode could be quieter2021-11-15T16:55:19Zteorchutney's --quiet mode could be quieterIt would be nice to get it down to just a few lines per run.It would be nice to get it down to just a few lines per run.https://gitlab.torproject.org/tpo/core/tor/-/issues/21716Avoid recursive call to routerlist_remove_old_routers via router_rebuild_store2022-02-28T19:41:05ZTracAvoid recursive call to routerlist_remove_old_routers via router_rebuild_storePeriodic functions have their log output duplicated when using adb logcat:
orbot/external/tor/src/or/periodic.c
static void
periodic_event_dispatch(evutil_socket_t fd, short what, void *data)
{
(void)fd;
(void)what;
periodic_even...Periodic functions have their log output duplicated when using adb logcat:
orbot/external/tor/src/or/periodic.c
static void
periodic_event_dispatch(evutil_socket_t fd, short what, void *data)
{
(void)fd;
(void)what;
periodic_event_item_t *event = data;
time_t now = time(NULL);
const or_options_t *options = get_options();
log_debug(LD_GENERAL, "Dispatching %s", event->name);
int r = event->fn(now, options);
I did uncomment the above log_debug which is then printed only once as expected.
The problem starts with r=events->fn(now, options);. Every function called this way seems to have its log output duplicated. I checked with builtin atomics that the function is actually called only once but the log output is duplicated, e.g.:
03-12 20:45:22.627 17948 17948 D Tor : periodic_event_dispatch(): Dispatching check_descriptor
03-12 20:45:22.637 17948 17948 I Tor : routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
03-12 20:45:22.637 17948 17948 I Tor : routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
This is somewhat irritating when tracing the flow of events.
**Trac**:
**Username**: ansteinhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21657Test to make sure we isolate or disable all speculative connects2023-01-05T17:16:53ZArthur EdelsteinTest to make sure we isolate or disable all speculative connectsThere are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
```
link rel=preconnect
link rel=prefetch
link rel=prerender
```
and possibly more.
We ...There are a variety of "resource hint" features in Tor Browser that we want to make sure are isolated by first-party or disabled. These include
```
link rel=preconnect
link rel=prefetch
link rel=prerender
```
and possibly more.
We should test this for the ESR45 and ESR52 versions of Tor Browser, because isolation will have different mechanisms.
See https://w3c.github.io/resource-hints/
We should also look into "SpeculativeConnect" code in Firefox to make sure there aren't any other cases of non-first-party isolated connections.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21610Hide about:profiles2023-11-27T09:35:33ZGeorg KoppenHide about:profiles`about:profiles` allows user things like creating new profiles or restarting with extensions disabled. This might lead to weird errors and there is probably no real use case in a Tor Browser context for that. We should hide it ideally wi...`about:profiles` allows user things like creating new profiles or restarting with extensions disabled. This might lead to weird errors and there is probably no real use case in a Tor Browser context for that. We should hide it ideally with an option to make it visible again if it is indeed needed for some reason.https://gitlab.torproject.org/tpo/core/chutney/-/issues/21543Make chutney use a different base port2021-11-15T16:54:15ZteorMake chutney use a different base portI often want to run multiple chutney networks at once.
It would help if I could specify a different base port (for example, 10000) that would be added to all ports used by chutney.I often want to run multiple chutney networks at once.
It would help if I could specify a different base port (for example, 10000) that would be added to all ports used by chutney.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21455newwin: Inconsistent New Window height on multiple monitors (Windows)2024-03-12T09:04:47ZTracnewwin: Inconsistent New Window height on multiple monitors (Windows)(1) "New Window" or Ctrl+N creates a new window slightly offset from the current window, but the size of the new window is determined by the primary display (instead of the display the window is on).
If the primary display is larger, th...(1) "New Window" or Ctrl+N creates a new window slightly offset from the current window, but the size of the new window is determined by the primary display (instead of the display the window is on).
If the primary display is larger, this can push part of the window off the top of the display (e.g. primary 1920x1200, secondary 1280x1024: New Window on secondary display gets pushed off the top so only half the URL bar is visible).
(2) Dragging a tab out of a window with multiple tabs creates a new window sized differently than "New Window", this new window is sized according to the display it is on.
This is in 6.5 and 7.0a1 but not 6.08
**Trac**:
**Username**: pjw0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21347Retrying a download breaks URL bar domain isolation2023-08-28T16:05:46ZGeorg KoppenRetrying a download breaks URL bar domain isolationIf a download fails and one tries to restart it via the `about:downloads` page the resumption goes over the catch-all circuit. It would be more intuitive is we could use the circuit previously used (if it is still available).
Reported o...If a download fails and one tries to restart it via the `about:downloads` page the resumption goes over the catch-all circuit. It would be more intuitive is we could use the circuit previously used (if it is still available).
Reported on our blog: https://blog.torproject.org/blog/tor-browser-70a1-released#comment-233304