The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-25T15:29:53Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1075Rework define_pk_keypair macro to generate a public() fn for all keypair types2023-10-25T15:29:53Zgabi-250Rework define_pk_keypair macro to generate a public() fn for all keypair types`define_pk_keypair` currently only generates key pair structs (and corresponding `public()`, etc. accessors) and for curve25519 keys. We might want to consider creating keypair structs for other key types too (this would enable us to ext...`define_pk_keypair` currently only generates key pair structs (and corresponding `public()`, etc. accessors) and for curve25519 keys. We might want to consider creating keypair structs for other key types too (this would enable us to extract the public part of any keypair using `kp.public()`)
The following discussion from !1689 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1689#note_2957096): (+1 comment)
> I think we should be able to get the public part of every keypair with a `public()` function. Do we not have one of those here? Several other keypairs have them.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40286On IPv6-only server, always "NAT type: unknown" even with firewall disabled2023-10-21T16:18:43Zcatharsis71On IPv6-only server, always "NAT type: unknown" even with firewall disabledI have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames w...I have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames with AAAA records resolve normally and go out directly
there is no access to raw IPv4 IP addresses
running snowflake-proxy, I always get "NAT type: unknown" even if my firewall is completely disabled... is this intended behavior?
I've tested both the Docker container and compiling/running locally but the results are the same
the proxy does seem to work but normally only gets 0-3 connections per hour per proxy (seemingly unaffected by whether the firewall is up or down)
perhaps this is due to the small pool of IPV6 clients wanting to connect, but I'm not sure
snowflake.torproject.net has an AAAA record so traffic to it does not go through NAT64
likewise stun.l.google.com has an AAAA record so traffic to it does not go through NAT64
I am unable to determine the cause of the "NAT type: unknown"https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/69Tool to manage Onion Service auth keys2023-10-20T16:17:37ZSilvio RhattoTool to manage Onion Service auth keysModule to create Onion Services authorization keys, given that [the current instructions](https://community.torproject.org/onion-services/advanced/client-auth/) are not very handy to follow. Some tool/library could automate this manageme...Module to create Onion Services authorization keys, given that [the current instructions](https://community.torproject.org/onion-services/advanced/client-auth/) are not very handy to follow. Some tool/library could automate this management in the server side.
Thanks @gus for the idea :-)https://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/core/arti-doc-project-2023/-/issues/10Pre-Kickoff Task2023-10-19T22:51:02ZharletaPre-Kickoff Task**Project Owners**
Name: Gaba
Github: N/A
**Point Person**
Name: Gaba
Github: N/A
Watchers 1
Name: Ahf
Email:
Github:
Watchers 2
Name:
Email:
Github:
---------------------------------------------------------------
Gaba...**Project Owners**
Name: Gaba
Github: N/A
**Point Person**
Name: Gaba
Github: N/A
Watchers 1
Name: Ahf
Email:
Github:
Watchers 2
Name:
Email:
Github:
---------------------------------------------------------------
Gaba is the primary contact for the project. Erin is on the financial side.
Ahf (Arti developer lead) is a collaborator
Other Arti developers are a collaborator
Gaba is ready to schedule a user interview right after the kickoff
---------------------------------------------------------------
Resources
Raw audit here
https://docs.google.com/spreadsheets/d/1h7AT4C4L5WiH_Svj8RZLCqkPekuohJIfgupkHlMV4RA/edit#gid=1976166458
Content Audit and UX report here
https://docs.google.com/document/d/1QmeejQaBnk3y4F8zyB2w9sx2ZzRZxSvTPLmCwkz7QbM/edit?usp=sharing
Notes, detail, recap for Arti public meeting (IRC): https://pad.riseup.net/p/arti-meeting-pad-keep
Current Project management sandbox: https://gitlab.torproject.org/tpo/core/arti/-/tree/main
Link to documentation: https://tpo.pages.torproject.net/core/arti/
Arti's latest blog: https://blog.torproject.org/arti_117_released/Charles MuzonziniCharles Muzonzinihttps://gitlab.torproject.org/tpo/core/arti/-/issues/1032TLS reads and writes are not effectively buffered2023-10-19T15:03:21ZMicah Elizabeth ScottTLS reads and writes are not effectively buffered<!--
* Use this issue template for reporting a new bug.
-->
### Summary
This issue comes from the investigation behind https://gitlab.torproject.org/tpo/core/arti/-/issues/786, a code cleanup ticket about auto-flushing copiers. Those c...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
This issue comes from the investigation behind https://gitlab.torproject.org/tpo/core/arti/-/issues/786, a code cleanup ticket about auto-flushing copiers. Those copiers are one tool in a toolbox of I/O buffering strategies, so it raises questions about how the tool is being used, for what, and how effectively. I tried to get some idea of our end-to-end buffering behavior in Arti using strace, and the trace shows some areas for improvement.
### Steps to reproduce:
1. Release build, `cargo build --release`
2. Trace Arti to a file, no string dumps, `strace -s 0 -o trace.log -f target/release/arti -o application.permit_debugging=true proxy`
3. Generate some load.. how about downloading a complex application over HTTP2, `curl -x socks5h://localhost:9150 -v https://www.youtube.com/ | less`
### What is the current bug behavior?
There are several places where we may potentially have buffering issues, I'm looking at them individually in this test.
The SOCKS end might be fine. Reads are buffered into 1024-byte chunks, a little small in general for user/kernel buffers but okay in practice for HTTP. I'd recommend increasing this to 8K or so by default.
The very small reads I'm seeing (5 bytes) are actually on the TLS end. The size and context would explain this as a TLS record header read. Normally this would be buffered, we are missing a buffering layer here. TLS is reading using syscall buffer sizes that match the TLS records.
Writes on the SOCKS end are never larger than 1 cell, even when larger buffers are being processed on the input side of the stream.
Trace excerpts below.
### What is the expected behavior?
Ideally every wakeup from epoll_wait should result in some number of full (8K or so) buffers exchanged per socket plus no more than one under-full buffer per socket.
The TLS connection definitely needs to be buffered, and ideally we would have a way to flush multiple cells at once to the kernel when multiple cells are processed per wakeup.
### Environment
<!--
Please fill in the following information in bug reports, removing the comments like this one in brackets.
-->
- Version: git main
- Operating system: debian sid
### Relevant logs and/or screenshots:
FD 15 is TLS, 16 is SOCKS.
```
2386747 epoll_wait(3, [...], 1024, 664) = 1
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 531, 0, NULL, NULL) = 531
2386747 recvfrom(15, 0x7fc090213833, 5, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
2386747 sendto(16, ""..., 31, MSG_NOSIGNAL, NULL, 0) = 31
2386747 epoll_wait(3, [...], 1024, 524) = 1
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 3679, 0, NULL, NULL) = 3679
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 3825
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 164, MSG_NOSIGNAL, NULL, 0) = 164
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 epoll_wait(3, [...], 1024, 481) = 1
2386747 recvfrom(15, ""..., 240, 0, NULL, NULL) = 240
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 81, 0, NULL, NULL) = 81
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 531, 0, NULL, NULL) = 531
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 581
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 310, MSG_NOSIGNAL, NULL, 0) = 310
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 11, MSG_NOSIGNAL, NULL, 0) = 11
2386747 epoll_wait(3, [...], 1024, 469) = 1
2386747 recvfrom(15, ""..., 3484, 0, NULL, NULL) = 2896
2386747 epoll_wait(3, [], 1024, 0) = 0
2386747 epoll_wait(3, [...], 1024, 363) = 1
2386747 recvfrom(15, ""..., 588, 0, NULL, NULL) = 588
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 1751, 0, NULL, NULL) = 1751
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 1045, 0, NULL, NULL) = 1045
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 81, 0, NULL, NULL) = 81
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 4065
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 1109, 0, NULL, NULL) = 1109
2386747 recvfrom(15, ""..., 5, 0, NULL, NULL) = 5
2386747 recvfrom(15, ""..., 4065, 0, NULL, NULL) = 2051
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 310, MSG_NOSIGNAL, NULL, 0) = 310
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 404, MSG_NOSIGNAL, NULL, 0) = 404
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
2386747 sendto(16, ""..., 498, MSG_NOSIGNAL, NULL, 0) = 498
```
### Possible fixes:
The missing buffers on TLS can be fixed by adding buffers presumably, but we need to be very careful about the end-to-end flush behavior in order to balance latency and overhead. Write buffering may need to be written with KIST in mind, but read buffering should be straightforwardly implementable.https://gitlab.torproject.org/tpo/applications/vpn/-/issues/108Automatted screenshotting2023-10-18T21:51:03ZcybertaAutomatted screenshottingUsing fastlane, we could write some instrumentation tests that help to automate screenshot generation.
These would help with the translations on the one hand, but also they allow us to get internationalized screenshots for the app store...Using fastlane, we could write some instrumentation tests that help to automate screenshot generation.
These would help with the translations on the one hand, but also they allow us to get internationalized screenshots for the app store for example.
As a drawback the initial setup and maintaining the screenshot tests requires some time. To not slow down the development, we should probably only screenshot views, that are somewhat considered settled design wise.
This ticket is open for discussion. ping @emmapeel @micah @donuts @ankitgusai19https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42180The circuit display is not shown when the bridge line doesn't contain the nod...2023-10-17T16:14:17ZPier Angelo VendrameThe circuit display is not shown when the bridge line doesn't contain the node fingerprintAs a sort of known bug, we cannot do much to associate fingerprints to bridges.
As a workaround, we use the bridge line to associate the address to the fingerprint.
But if the user don't supply it, we cannot recognize they're using a br...As a sort of known bug, we cannot do much to associate fingerprints to bridges.
As a workaround, we use the bridge line to associate the address to the fingerprint.
But if the user don't supply it, we cannot recognize they're using a bridge and query the control port for the IP address as it was a normal relay.
The control port answers with an error that as ultimate consequence makes the circuit display disappear for that page.
This is easily checkable by requesting a vanilla bridge on https://bridges.torproject.org/, and then copying only the IP address and port without the fingerprint.
I discovered that we can at least get bridge fingerprints with `GETINFO downloads/bridge/bridges`. E.g.:
```
GETINFO downloads/bridge/bridges
250+downloads/bridge/bridges=
8838024498816A039FCBBAB14E6F40A0843051FA
2B280B23E1107BB62ABFC40DDCC8824814F80A72
.
250 OK
GETINFO downloads/bridge/bridges
551 We don't seem to be using bridges
```
That would be helpful, because at least we'd have a way to be sure we are dealing with a bridge. I'd say creating a set of bridges would be quite cheap to do every time in the query for the information about a node.
In some cases we can also get IP addresses with `GETINFO ns/purpose/bridge`, in a format similar to the one for normal relays, e.g.:
```
r Unnamed fingerprint-in-base64 something-else some-date ipv4 port 0
a ipv6:port
s Running
w Bandwidth=...
p reject 1-65535
```
However, this includes many bridges, there isn't a way to filter only on the fingerprint we want to know ~~, but what's worse is that it might not contain all (e.g., Snowflake wasn't included in my tests)~~ (Snowflake isn't working in my dev build for some reason :shrug:).
Anyway, I wonder if we should add an "Unknown" item in the circuit display when we cannot get the information in any way, and display the other nodes.
The problem was spotted by [NoOp21](https://forum.torproject.org/t/new-release-tor-browser-13-0/9703/18) in the 13.0 release thread.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42107Strange connection issue with gitlab.io subdomains2023-10-17T10:47:20ZnervuriStrange connection issue with gitlab.io subdomainsFor Tor Browser (both 12.5.4 and 13.0a4) on Debian, gitlab.io subdomains fail to load on the first connection, but work on subsequent connections. The TLS handshake appears to fail on the first connection. There are, however, rare exce...For Tor Browser (both 12.5.4 and 13.0a4) on Debian, gitlab.io subdomains fail to load on the first connection, but work on subsequent connections. The TLS handshake appears to fail on the first connection. There are, however, rare exceptions in which the connection does work on the first try.
I have provided more details in [**this forum post**](https://forum.torproject.org/t/strange-issue-with-gitlab-io-subdomains/8265). There's also [**a reply by PieroV**](https://forum.torproject.org/t/strange-issue-with-gitlab-io-subdomains/8265/7) in which he lays out a hypothesis for why this is happening. This problem does not occur on Windows and Android.
The mystery is: why does it only happen on gitlab.io subdomains and why only for the GNU/Linux version of Tor Browser? Is it a purely local problem in TBB’s code, or can GitLab’s firewall tell that the first and second visits were made within the same browsing session? If so, how? What gives it away? It has to be a TCP or TLS-level thing, as HTTP isn't used in the first connection attempt.
Also, Tor Browser has the same JA3 fingerprint on both Linux and Android, their TLS configurations seem to be identical. So if it’s some kind of firewall issue on GitLab’s end, why doesn’t it block them both? How does it tell them apart? And how does it tell the first and second visits apart?
Example links to test with:
* https://charts.gitlab.io/
* https://sigvids.gitlab.io/
* https://wolfree.gitlab.io/
* https://tpoforks.gitlab.io/tor-browser-manual/
* https://oniondocs.gitlab.io/tbmanual/
I want to underscore that there are two parts to this issue:
1. Explaining why this happens (important).
2. Stopping it from happening (less important).
There's also a third, UI-related problem connected to this, I've created a separate issue for it: #42108.https://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/applications/mullvad-browser/-/issues/147On macOS, the launcher uses the stable icon even when alpha2023-10-16T21:19:18ZruihildtOn macOS, the launcher uses the stable icon even when alphaWhen installing the browser on macOS, the icon in the Applications folder and in the browser are correctly using the green alpha version.
However, the launcher icon in the bar is using the stable yellow version.When installing the browser on macOS, the icon in the Applications folder and in the browser are correctly using the green alpha version.
However, the launcher icon in the bar is using the stable yellow version.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42178New Tor circuit for this site (hamburger menu) is always visible/clickable2023-10-16T21:16:11ZPier Angelo VendrameNew Tor circuit for this site (hamburger menu) is always visible/clickableWe always show the "New Tor circuit for this site" in the hamburger menu.
Would it make sense to hide it for things such as about pages?
Before taking a decision, we should consider that maybe it's the only way to change the catchall c...We always show the "New Tor circuit for this site" in the hamburger menu.
Would it make sense to hide it for things such as about pages?
Before taking a decision, we should consider that maybe it's the only way to change the catchall circuit.https://gitlab.torproject.org/tpo/core/torspec/-/issues/225Overlap in `dir-spec` grammar2023-10-16T16:21:22ZEmil EnglerOverlap in `dir-spec` grammarHave a look at the following lines in the dir-spec grammar:
```
KeywordLine ::= Keyword (WS Argument)* NL
Argument := ArgumentChar+
ArgumentChar ::= any graphical printing ASCII character.
```
The `WS` token in `KeywordLine` seems to be...Have a look at the following lines in the dir-spec grammar:
```
KeywordLine ::= Keyword (WS Argument)* NL
Argument := ArgumentChar+
ArgumentChar ::= any graphical printing ASCII character.
```
The `WS` token in `KeywordLine` seems to be wrong considering that `ArgumentChar` may contain `WS` as well (ASCII space is usually considered a printable character). This confuses parsers following this particular grammar.https://gitlab.torproject.org/tpo/core/arti/-/issues/1012Consider using `cackle` to check our dependencies' API usage2023-10-14T10:59:54ZNick MathewsonConsider using `cackle` to check our dependencies' API usageThis looks potentially interesting: https://crates.io/crates/cackle
It audits crates to make sure they aren't calling anything that you think they shouldn't.This looks potentially interesting: https://crates.io/crates/cackle
It audits crates to make sure they aren't calling anything that you think they shouldn't.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42032Opening NoScript settings before the bootstrap opens about:blank2023-10-11T21:41:00ZPier Angelo VendrameOpening NoScript settings before the bootstrap opens about:blankWe get this permission error:
```
Security Error: Content at moz-extension://c725a3ae-a1ae-4fa9-a895-f27a86f59f86/ may not load or link to about:torconnect?redirect=moz-extension%3A%2F%2Fc725a3ae-a1ae-4fa9-a895-f27a86f59f86%2Fui%2Fpopup...We get this permission error:
```
Security Error: Content at moz-extension://c725a3ae-a1ae-4fa9-a895-f27a86f59f86/ may not load or link to about:torconnect?redirect=moz-extension%3A%2F%2Fc725a3ae-a1ae-4fa9-a895-f27a86f59f86%2Fui%2Fpopup.html%23tab1.
```
Steps to reproduce:
1. Open the browser, and stay on `about:torconnect`
2. Right click on NoScript (you'll need to click on its icon in the Extensions panel)
3. Click again on NoScript
4. You will get an empty about:blank
Probably, we should not redirect `moz-extension` URLs, and let that other page load.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42105Mullvad Browser (maybe tor browser) on win11 with Desktop on Onedrive becomes...2023-10-11T21:40:15ZDan BallardMullvad Browser (maybe tor browser) on win11 with Desktop on Onedrive becomes unrunnableWill need more testing to reproduce, but a new laptop I was helping setup defaulted to Desktop on OneDrive. Mullvad Browser installed to desktop, ran, but shortly later could not be run. The `Start Mullvad Browser` link lined to Mullvard...Will need more testing to reproduce, but a new laptop I was helping setup defaulted to Desktop on OneDrive. Mullvad Browser installed to desktop, ran, but shortly later could not be run. The `Start Mullvad Browser` link lined to Mullvard Browser/Browser which was gone.
A little checking, OneDrive is case insensitive, I believe the fact we have a `Browser` executable and `browser` directory caused some collision cus sure enough, a bit after installing the `Browser` executable disappeared and Mullvad Browser was unrunnable. We've just unlinked OneDrive from the computer and it seems this is no longer happening.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41787Purple tor buttons use white text in both light and dark theme2023-10-11T21:38:25ZhenryPurple tor buttons use white text in both light and dark themeCurrent both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab....Current both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41608#note_2895231:
> in the figma mockups the "Connect" button uses almost-white text with a light theme, and almost-black text with a dark theme.
>
> In contrast the ".onion available" urlbar button always uses white text, regardless of theme:
>
> ![onion available button in dark mode](https://gitlab.torproject.org/tpo/applications/tor-browser/uploads/dac4112fc2b8aa6d21c65bb76cda4e25/onion-available-dark-mode.png)
And the reply from @donuts
> The two variants are supposed to use `purple-60` (light theme) and `purple-30` (dark theme) for backgrounds, and the normal label color for foregrounds (e.g. page-color, I think?).
>
> For consistency, maybe we should ignore the dark theme variant for now, and we can open a separate issue to fix this everywhere (i.e. torconnect, onion-location, and this instance).henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42106SessionFileInternal.getWriter() called too early in new identity2023-10-11T21:37:25ZJeremyRandSessionFileInternal.getWriter() called too early in new identityWhile debugging #42085, Patrick from Whonix [took a log from the Tor Browser JS console](http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/14) aft...While debugging #42085, Patrick from Whonix [took a log from the Tor Browser JS console](http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/tor-browser-refactored-control-port-tor-daemon-codebase/17164/14) after the fixes from @pierov's testbuild were applied. There are still a few errors showing up in the log. Neither Patrick nor I am confident about whether they're harmless, so probably someone should investigate them.
The most concerning (to my untrained eye) log entries are:
```
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIAppStartup.secondsSinceLastOSRestart]
_collectStartupConditionsTelemetry resource:///modules/BrowserGlue.sys.mjs:1649
BG__onFirstWindowLoaded resource:///modules/BrowserGlue.sys.mjs:1759
BG_observe resource:///modules/BrowserGlue.sys.mjs:981
_delayedStartup chrome://browser/content/browser.js:2106
BrowserGlue.sys.mjs:1658:15
```
```
uncaught exception: SessionFileInternal.getWriter() called too early! Please read the session file from disk first. 2
```
```
TypeError: this.client is undefined
RemoteSecuritySettings.sys.mjs:538:7
```
See the above forum link for full context on where the errors show up in the log. I have no idea whether these errors also show up in non-Whonix environments. To be clear, Patrick isn't observing any actually-wrong *behavior*, so *probably* everything is OK... but seems better to check than assume.https://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/applications/tor-browser/-/issues/42062Review the SOCKS preference update2023-10-11T17:37:36ZPier Angelo VendrameReview the SOCKS preference updateIn one of the refactors that lead to `TorProvider`, a few important points about settings the SOCKS preferences emerged (see https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/721#note_2934453):
- it isn't clear...In one of the refactors that lead to `TorProvider`, a few important points about settings the SOCKS preferences emerged (see https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/721#note_2934453):
- it isn't clear why we first read, do stuff and then write
- might be needed if we want not to hardcode the SOCKS port number, see #40930
- environment variables will change the value of a pref, so they're not consistent with the control port env variables, that are one-time only
- we could/should use another set of preferences that don't overlap with the browser's settings