The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-06T10:15:40Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1088Generate revision counters by encrypting the timestamp2023-11-06T10:15:40Zgabi-250Generate revision counters by encrypting the timestampWe're currently using the "Increment-on-generation" approach described in rend-spec-v3 Appendix F.1., except the revision counter is **not** persisted across restarts. A service restarting after publishing a descriptor with the revision ...We're currently using the "Increment-on-generation" approach described in rend-spec-v3 Appendix F.1., except the revision counter is **not** persisted across restarts. A service restarting after publishing a descriptor with the revision counter set to `N` will fail to republish its descriptors after the restart, because the HSDirs will reject any new descriptors that have a revision counter < `N + 1` (the revision counter is incremented when the time period changes or when the IPTs change, so the service will succeed in republishing its descriptors, as the revision counter will reach `N + 1`).
We need to replace this with the OPE-encryption based approach from Appendix F.2.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1087What to do with data and keys from no-longer-configured onion services?2024-02-21T15:09:58ZNick MathewsonWhat to do with data and keys from no-longer-configured onion services?We should define some mechanism to decide how long to keep persistent state and keys for onion services that are **not configured** or **not running**.
(For deleting expired keys from running onion services, see #1198)
If we were to de...We should define some mechanism to decide how long to keep persistent state and keys for onion services that are **not configured** or **not running**.
(For deleting expired keys from running onion services, see #1198)
If we were to delete them immediately, it wouldn't be possible to turn an onion service off and on again, which might surprise some users. But if we were were to keep them forever, that would present a surprising behavior, since users might not expect to retain information about expired onion keys forever.Arti: Onion Service Securityhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42213Fluent migration: tor launcher2023-11-06T23:11:11ZhenryFluent migration: tor launcherMigrate "torlauncher.properties" to Fluent.Migrate "torlauncher.properties" to Fluent.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42212Fluent migration: onion services2023-11-07T16:13:42ZhenryFluent migration: onion servicesMigrate onion services strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.Migrate onion services strings found in "torbutton.dtd" and "torbutton.properties" to Fluent.henryhenryhttps://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/anti-censorship/pluggable-transports/snowflake/-/issues/40302Proxy hourly stats did not actually happen during that hour2023-10-30T16:44:18ZRoger DingledineProxy hourly stats did not actually happen during that hourMy snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relaye...My snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relayed ↓ 561833 KB, ↑ 97282 KB.
2023/10/27 11:53:58 In the last 1h0m0s, there were 63 connections. Traffic Relayed ↓ 124717270 KB, ↑ 6237157 KB.
2023/10/27 12:53:58 In the last 1h0m0s, there were 48 connections. Traffic Relayed ↓ 745608 KB, ↑ 97699 KB.
```
That "125 gigabytes" entry translates to... almost 35 megabytes per second of traffic, on average during the hour? Probably by only a few or even one user? This did not happen during that hour.
Looking at proxy/lib/pt_event_logger.go:
```
case event.EventOnProxyConnectionOver:
e := e.(event.EventOnProxyConnectionOver)
p.inboundSum += e.InboundTraffic
p.outboundSum += e.OutboundTraffic
p.connectionCount += 1
```
I.e. what is happening here is that the stats for the entire connection are counted during the hour that it closed.
See the forum for somebody else reporting this same issue (forum post noticed courtesy MarkC on irc): https://forum.torproject.org/t/impossible-metric-for-snowflake-proxy/9941/1
We should either (a) make the hourly "In the last 1h0m0s," be accurate, in the sense that they actually tell me what happened in the last 1h0m0s, or (b) change the log message so it's clearer it is telling me how many connections finished during that hour along with total transfer on those recently-closed connections.
I'd prefer solution 'a', since it is what I thought I was getting out of these log entries, and I was using it to e.g. try to judge what timezones my snowflake is popular.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-28T09:06:29ZdonutsCorrectly 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.