The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-26T09:06:47Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42208Fluent migration: tor connect2024-03-26T09:06:47ZhenryFluent migration: tor connectMigrate "torConnect.properties" to Fluent. Maybe coordinate with possible strings changes from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41621.Migrate "torConnect.properties" to Fluent. Maybe coordinate with possible strings changes from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41621.henryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1086Stream timeout error kind/message is confusing2023-11-15T19:00:22ZoparaStream timeout error kind/message is confusing### Summary
If a stream times out, the error message seems to imply it's an `ExitTimeout`, but the `kind()` is not `ExitTimeout`.
### What is the expected behavior?
```rust
// arti_client 0.10.2
use arti_client::config::TorClientConfi...### Summary
If a stream times out, the error message seems to imply it's an `ExitTimeout`, but the `kind()` is not `ExitTimeout`.
### What is the expected behavior?
```rust
// arti_client 0.10.2
use arti_client::config::TorClientConfigBuilder;
use arti_client::HasKind;
use arti_client::TorClient;
#[tokio::main]
async fn main() -> arti_client::Result<()> {
let mut builder = TorClientConfigBuilder::default();
builder
.stream_timeouts()
.connect_timeout(std::time::Duration::from_micros(10));
let tor_client = TorClient::create_bootstrapped(builder.build().unwrap()).await?;
let connection = tor_client.connect(("example.com", 80)).await;
if let Err(e) = connection {
println!("Error: {e} - {e:?}");
println!("Error kind(): {}", e.kind());
println!(
"Is ExitTimeout? {}",
matches!(e.kind(), arti_client::ErrorKind::ExitTimeout)
);
}
Ok(())
}
```
Output:
```
Error: tor: operation timed out at exit: Timed out while waiting for answer from exit - Error { detail: ExitTimeout }
Error kind(): operation timed out at exit
Is ExitTimeout? false
```
The error messages all seem to indicate that it's an `ExitTimeout`, but the actual kind is `RemoteNetworkTimeout`. What makes it more confusing is that `ExitTimeout` is an actual kind. So if you see the above error message and then try to match on the error with something like `Err(e) if e.kind() == ExitTimeout`, it will compile but you won't actually catch the error properly.Arti: Feature parity with the C implementationhttps://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/onion-services/sauteed-onions/monitor/-/issues/6Check that matches are really onion addresses2023-10-27T15:09:33ZRasmus Dahlbergrasmus@rgdd.seCheck that matches are really onion addressesSee https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/monitor/-/blob/main/scripts/reap-onions.sh?ref_type=heads#L6
I.e., would be nice to not just say "any 56 bytes".See https://gitlab.torproject.org/tpo/onion-services/sauteed-onions/monitor/-/blob/main/scripts/reap-onions.sh?ref_type=heads#L6
I.e., would be nice to not just say "any 56 bytes".https://gitlab.torproject.org/tpo/community/l10n/-/issues/40126Improve Access Keys documentation: explain difference to shortcuts2024-01-24T21:11:50ZemmapeelImprove Access Keys documentation: explain difference to shortcutsWe already have some documentation about Access Keys: https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-translators#access-keys
But it needs to be improved.
We need to differentiate Access Keys, that are a way t...We already have some documentation about Access Keys: https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-translators#access-keys
But it needs to be improved.
We need to differentiate Access Keys, that are a way to navigate menus, from keyboard shortcuts.
One difference: Shortcuts are the same for all locales, Access Keys depend on the locale.
ref: https://hosted.weblate.org/translate/tor/tor-browser/tb-newidentityproperties/ru/?checksum=73b4988ed95a84d9#commentshttps://gitlab.torproject.org/tpo/core/arti/-/issues/1078hsclient: Rename `get_or_launch_connection` to `get_or_launch_circuit`?2023-10-24T17:15:37ZNick Mathewsonhsclient: Rename `get_or_launch_connection` to `get_or_launch_circuit`?In many cases we avoid using the term "connection" because it tends to be vague about whether we mean a channel, a stream, or a circuit. I just hit this confusion with `get_or_launch_connection` in tor-hsclient: I was uncertain by lookin...In many cases we avoid using the term "connection" because it tends to be vague about whether we mean a channel, a stream, or a circuit. I just hit this confusion with `get_or_launch_connection` in tor-hsclient: I was uncertain by looking at the name whether it would give a circuit, a stream, or some weird third thing.
We may want to keep the old name but deprecate it. If not, we should mark this as a breaking change.Nick MathewsonNick Mathewsonhttps://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/onion-services/onionprobe/-/issues/82Create an Onionprobe release on new tags2024-03-27T21:44:40ZSilvio RhattoCreate an Onionprobe release on new tagsCreate a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/) automatically [when a tag is pushed to the repo](https://docs.gitlab.com/ee/user/project/releases/release_cicd_examples.html#create-a-release-when-a-git-tag-is-...Create a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/) automatically [when a tag is pushed to the repo](https://docs.gitlab.com/ee/user/project/releases/release_cicd_examples.html#create-a-release-when-a-git-tag-is-created).Onionprobe 1.2.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/onion-services/oniongroove/-/issues/5Vendorize Onion MkDocs2024-03-27T21:47:27ZSilvio RhattoVendorize Onion MkDocsVendorize [Onion MkDocs](https://gitlab.torproject.org/rhatto/onion-mkdocs), so it's easier to retrieve updates.Vendorize [Onion MkDocs](https://gitlab.torproject.org/rhatto/onion-mkdocs), so it's easier to retrieve updates.Oniongroove 0.1.0Silvio RhattoSilvio Rhatto2024-05-16https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40988Make tool to compare signed and unsigned dmg2023-11-16T12:21:47ZboklmMake tool to compare signed and unsigned dmgSince macos code signing is modifying binary files to embed code
signatures, it is not easy to check that the dmg from our reproducible
build and the signed dmg we publish are the same apart from the
signatures.
I think we could make a ...Since macos code signing is modifying binary files to embed code
signatures, it is not easy to check that the dmg from our reproducible
build and the signed dmg we publish are the same apart from the
signatures.
I think we could make a tool to compare a signed and unsigned dmg.
It seems there is a `codesign --remove-signature` command that can be
used on macos to remove signatures. I don't know if the same can be done
on linux.
Maybe `rcodesign compute-code-hashes` can also help for that.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42193Focus the bridge textarea automatically when opening the provide a bridge man...2023-11-01T18:09:46ZPier Angelo VendrameFocus the bridge textarea automatically when opening the provide a bridge manuallyThis was a user suggestion in https://forum.torproject.org/t/new-release-tor-browser-13-0/9703/45:
> Another minor thing i found:
>
> In some previous version of Tor Browser the textbox for manually adding a bridge was already marked so...This was a user suggestion in https://forum.torproject.org/t/new-release-tor-browser-13-0/9703/45:
> Another minor thing i found:
>
> In some previous version of Tor Browser the textbox for manually adding a bridge was already marked so you could Ctrl+V right away.
>
> Now you first have to click in the box to be able to paste.
I think it makes sense.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42192Correctly round new windows when bookmarks toolbar is set to "Only Show on Ne...2024-03-28T15:26:58ZdonutsCorrectly round new windows when bookmarks toolbar is set to "Only Show on New Tab"This has happened at least twice to me, but I have no idea how to reproduce it.
On first launch, the viewport in Tor Browser 13.0 is 900px high and unletterboxed. After a period of several days, an additional 30px appears to get added t...This has happened at least twice to me, but I have no idea how to reproduce it.
On first launch, the viewport in Tor Browser 13.0 is 900px high and unletterboxed. After a period of several days, an additional 30px appears to get added to the height of the overall window, increasing the viewport to 930px and triggering letterboxing.
Note: this is not due to changes in the height of the browser chrome eating into the viewport (e.g. the bookmarks bar being on or off), as the height of the entire window has increased by 30px.
Tor Browser will then reliably reopen itself at the new dimensions even when quit and relaunched. Wiping the TorBrowser-Data file from macOS' Application Support folder seems to reset the browser back to its original dimensions, however.
<details><summary>Show screenshot</summary>
![letterboxing-error](/uploads/a23e2bbbad31b4a4d0ac2d6a33f1c445/letterboxing-error.png)
</details>ma1ma1https://gitlab.torproject.org/tpo/core/arti/-/issues/1073Use buffered readers around our socks connections2023-11-13T14:53:04ZNick MathewsonUse buffered readers around our socks connectionsWhile working on #786, @beth noticed that we do some tiny reads in our SOCKS implementation, and we should probably add a buffered reader to make those not result in tiny syscalls.
This isn't a huge issue; we can do it whenever. The cod...While working on #786, @beth noticed that we do some tiny reads in our SOCKS implementation, and we should probably add a buffered reader to make those not result in tiny syscalls.
This isn't a huge issue; we can do it whenever. The code to change is in `arti::socks` and `chanmgr::transport::proxied`.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1072Make DataWriter flush its own buffers, possibly on a timer, possibly after ci...2023-11-06T21:44:09ZNick MathewsonMake DataWriter flush its own buffers, possibly on a timer, possibly after circuitmux/KISTAfter a long discussion on #786, I think we concluded that bytes written to `DataWriter` should get flushed eventually, even if nobody calls `flush()` on the `DataWriter`. This will make it easier to drop in our `DataWriter` in place of...After a long discussion on #786, I think we concluded that bytes written to `DataWriter` should get flushed eventually, even if nobody calls `flush()` on the `DataWriter`. This will make it easier to drop in our `DataWriter` in place of other `AsyncWriter` implementations that expect this kind of behavior, and make our `copy_interactive` implementation unnecessary.
## Okay, so when _should_ we flush?
We probably don't want `write()` to flush immediately, since doing so would needlessly create a bunch of mostly empty cells. We might want to apply something like Nagle's algorithm here (though Nagle's algorithm itself is dependent TCP details that we might not share).
Another approach we could take is to flush in a way that is partially aware of circuit and channel fullness. When we finally implement circuitmux and kist-lite cell orchestrators, we'll know when a channel is under-used, when a circuit is ready to write something, and which streams a circuit would _like_ to read from. Then we could get more of a pull-based mechanism based on what's ready to write, and we wouldn't need to flush at all.
## And when should we implement this?
That I'm not so certain of. It might be a fine idea to implement an easy version of this (not aware of circuit state) so that we can get our interface's behavior more like what users expect, and throw away `copy_interactive`. On the other hand, if it would be a lot of effort, we shouldn't do that, and we should just wait till the time is right to do the hard thing.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42190TB13 is sending "Accept-Encoding: gzip, deflate, br" to http://onion while ot...2023-11-01T18:09:37ZcypherpunksTB13 is sending "Accept-Encoding: gzip, deflate, br" to http://onion while other browser send "Accept-Encoding: gzip, deflate". "br" requires HTTPS connection.TB13 is sending "Accept-Encoding: gzip, deflate, br" to http://onion while other browser send "Accept-Encoding: gzip, deflate". "br" requires HTTPS connection.TB13 is sending "Accept-Encoding: gzip, deflate, br" to http://onion while other browser send "Accept-Encoding: gzip, deflate". "br" requires HTTPS connection.https://gitlab.torproject.org/tpo/core/torspec/-/issues/226Is optimistic data allowed on onion services? And should it be?2023-11-09T14:30:21ZNick MathewsonIs optimistic data allowed on onion services? And should it be?While working on Arti, I've noticed that optimistic data on onion services might or might not be officially allowed. On the one hand, it will improve performance, since the client won't have to wait for a `CONNECTED` in order to send da...While working on Arti, I've noticed that optimistic data on onion services might or might not be officially allowed. On the one hand, it will improve performance, since the client won't have to wait for a `CONNECTED` in order to send data. On the other hand, it smells like a possible side channel vector (q.v. proposal 344) if the client chooses a `BEGIN` message that they know will provoke an `END` but not cause the circuit to close.
cc @mikeperry: what do you think?Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1066Rethink the ArtiPath pattern matching APIs2023-11-15T14:21:45Zgabi-250Rethink the ArtiPath pattern matching APIsThe following discussion from !1677 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1677#note_2955707): (+1 comment)
> I don't thnk C Tor even store `K_hs_blin...The following discussion from !1677 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1677#note_2955707): (+1 comment)
> I don't thnk C Tor even store `K_hs_blind_id` on disk. At least, that's what my reading of `tor(1)` from manpages.debian.org suggests.
>
> Anyway, I think the need to write this rather strange pattern demonstrates that the pattern API is wrong. You should be allowed to ask for keys by only their `ArtiPath`, and maybe only by their C Tor path.
>
> Suggested disposition: add a TODO HSS, or a ticket. Possibly invite me to demonstrate what I think the alternative looks like.Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/community/l10n/-/issues/40123Retire HTTPS_Everywhere translations2023-12-11T11:23:32ZemmapeelRetire HTTPS_Everywhere translationsFrom their website:
##Update on HTTPS Everywhere
⚠️This project is no longer being maintained or updated. Please uninstall and direct users to the advice below to switch to HTTPS by default natively.
You no longer need HTTPS Everywhe...From their website:
##Update on HTTPS Everywhere
⚠️This project is no longer being maintained or updated. Please uninstall and direct users to the advice below to switch to HTTPS by default natively.
You no longer need HTTPS Everywhere to set HTTPS by default! Major browsers now offer native support for an HTTPS only mode. Find out how to turn it on here.
This extension will be sunset by January 2023.
We need to retire the component, and we can use the opportunity to update the Howto retire a translation: https://gitlab.torproject.org/tpo/community/l10n/-/wikis/L10n-Coordinator#how-to-retire-a-localization-resourceemmapeelemmapeelhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42184Setting "Homepage and new windows" ignores "Blank Page" value2023-11-26T15:38:20Zpf.teamSetting "Homepage and new windows" ignores "Blank Page" valueSteps to reproduce:
1. Run TB 13.0.
2. Open: about:preferences#home
3. Set "Homepage and new windows" to the "Blank Page" value.
4. Restart TB.
Environment: Linux (x86_64).
Expected result: a new TB instance shows about:blank page.
A...Steps to reproduce:
1. Run TB 13.0.
2. Open: about:preferences#home
3. Set "Homepage and new windows" to the "Blank Page" value.
4. Restart TB.
Environment: Linux (x86_64).
Expected result: a new TB instance shows about:blank page.
Actual result: a new TB instance shows about:tor page.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42182Default Search Engine Does Not Persist Through Shift to New Identity2023-10-20T16:25:27ZCCRhodeDefault Search Engine Does Not Persist Through Shift to New Identity<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Default Search Engine Does Not Persist Through Shift to New Identity**
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1....<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Default Search Engine Does Not Persist Through Shift to New Identity**
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Install tor-browser-linux-x86_64-13.0.tar.xz
2. Start ./start-tor-browser.desktop
3. Hamburger > Settings > Search > Find More Search Engines
4. From https://addons.mozilla.org/en-US/firefox/extensions/category/search-tools/ search for brave
5. Install "Brave Search" by Dusan Uveric
6. Hamburger > Settings > Search > Default Search Engine > Brave
7. Hamburger > Quit
8. Start ./start-tor-browser.desktop
9. Hamburger > Settings > Search
10. Note that Default Search Engine is set to "Brave"
11. Hamburger > New Identity
12. Hamburger > Settings > Search
13. Note that Default Search Engine has been reset to DDG
### What is the current bug behavior?
**Shifting to New Identity resets the Default Search Engine.**
### What is the expected behavior?
**The Default Search Engine setting ought to be preserved through a shift to New Identity.**
### Environment
**Linux version 5.10.0-26-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.197-1 (2023-09-29)**
**TBB was installed from *tar* archive.**
### Relevant logs and/or screenshotsma1ma1