The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-10-20T21:10:44Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/564Make tor-rtcompat traits sealed in 1.02022-10-20T21:10:44ZNick MathewsonMake tor-rtcompat traits sealed in 1.0We've realized today that, although `tor-rtcompat` is an important piece of our public API, we do not currently plan to declare it `1.0`. That is, we need to make sure that we can continue to improve its feature set even as we keep `art...We've realized today that, although `tor-rtcompat` is an important piece of our public API, we do not currently plan to declare it `1.0`. That is, we need to make sure that we can continue to improve its feature set even as we keep `arti_client` stable.
To do this, we plan to make the traits in `tor-rtcompat` sealed by default for now, with an optional `unseal-traits` feature to unseal them.
@Diziet has taken this on.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/533Global "tradeoffs", "security", "perf" config options2022-10-20T21:09:07ZIan Jacksoniwj@torproject.orgGlobal "tradeoffs", "security", "perf" config optionsIn https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826155 we discussed a global config option I introduced for controlling various kinds of padding. I'm going to remove that from that branch for now, but:
We will...In https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826155 we discussed a global config option I introduced for controlling various kinds of padding. I'm going to remove that from that branch for now, but:
We will want a central place to configure "please run a config profile suitable for a phone" or some such.
@nickm writes there:
> I don't think this is "global" so much as "security" or "tradeoffs" or "performance" or something.
If we can think of a good name for this, it could contain setting like `mobile` which changes many things all at once.
I'm keen to have something like this, because otherwise we'll end up with cargo-culted config files full of "mobile friendly" tuning parameters floating around, and embedders will each make up their own[1], etc.
[1] Of course embedders might have good reasons to deviate from defaults, but we should supply a good set of defaults for this kind of widespread use case that we're aware of.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/524Move more config reading code into arti-client2022-10-20T21:09:20ZIan Jacksoniwj@torproject.orgMove more config reading code into arti-clienthttps://gitlab.torproject.org/tpo/core/arti/-/merge_requests/630#note_2822052
Discussing the code in `crates/arti/src/lib.rs` where `cfg_mistrust` etc. is made.
> This recapitulation of the mistrust construction bothered me somewhat. I...https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/630#note_2822052
Discussing the code in `crates/arti/src/lib.rs` where `cfg_mistrust` etc. is made.
> This recapitulation of the mistrust construction bothered me somewhat. I'm not sure, but I wonder if it woudl be better to move building of cfg_sources and the associated manipulation of the mistrust, into arti-client. The function in arti-client would take fs_mistrust_disabled. It would have to be generic over the relevant traits from tor_config::load.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/500define_list_builder_accessors contrives to hide documentation2022-10-20T21:09:13ZIan Jacksoniwj@torproject.orgdefine_list_builder_accessors contrives to hide documentationBecause `define_list_builder_accessors` is not a derive macro, it does not receive the struct definition. So the docs for the generated accessors are formulaic. That part is kind of OK, but the actual docs for the field end up *only* i...Because `define_list_builder_accessors` is not a derive macro, it does not receive the struct definition. So the docs for the generated accessors are formulaic. That part is kind of OK, but the actual docs for the field end up *only* in the docs for the main struct field. Which is private.
So overall, the docs are hidden.
I think the fix is to move the public docs from the list struct fields to into the macro call. I experimented with this and it seems to work.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/443Reconfiguration, particularly socks and dns ports2022-10-20T21:12:38ZIan Jacksoniwj@torproject.orgReconfiguration, particularly socks and dns portsWe should be able to add and remove socks and dns listeners. And the existing reconfiguration code's approach to error handling and reporting is not very principled.
!440 is a stab at this but is currently postponed.We should be able to add and remove socks and dns listeners. And the existing reconfiguration code's approach to error handling and reporting is not very principled.
!440 is a stab at this but is currently postponed.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/408CLI: unify, streamline, and refactor listener code2022-12-18T21:03:06ZNick MathewsonCLI: unify, streamline, and refactor listener codeRight now we have two kinds of listeners: DNS and SOCKS. We should consider simplifying the logic that creates them a lot.
Some goals are:
* [ ] Eliminate duplicate code.
* [ ] Allow multiple listener ports of the same type.
* [ ...Right now we have two kinds of listeners: DNS and SOCKS. We should consider simplifying the logic that creates them a lot.
Some goals are:
* [ ] Eliminate duplicate code.
* [ ] Allow multiple listener ports of the same type.
* [ ] Allow listening on non-localhost addresses
* [ ] Fail with an error if the port binding fails for some reason other than "we don't support that address family."Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/363Support for binding low ports, then dropping privileges2022-12-18T21:03:06ZNick MathewsonSupport for binding low ports, then dropping privilegesWe should have support for dropping our bind-low-port privileges (possibly with a setuid, possibly with a nicer os-specific mechanism) after using them.
Tangentially related to #331.We should have support for dropping our bind-low-port privileges (possibly with a setuid, possibly with a nicer os-specific mechanism) after using them.
Tangentially related to #331.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/362Integration support for systemd and similar systems2022-10-20T21:11:27ZNick MathewsonIntegration support for systemd and similar systems@diziet says this won't be too hard. Some stuff we might want:
* watchdog support
* letting the launcher know when we're bootstrapped
* socket-based activation.
We should make sure we work systemd and with the most popular non-syst...@diziet says this won't be too hard. Some stuff we might want:
* watchdog support
* letting the launcher know when we're bootstrapped
* socket-based activation.
We should make sure we work systemd and with the most popular non-systemd launcher system, so as to improve our odds of working everywhere else too.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/289initial_predicted_ports and handling during reconfigure2022-08-11T14:26:52ZIan Jacksoniwj@torproject.orginitial_predicted_ports and handling during reconfigureCurrently (if the docs are to be believed) an attempt to change this field on reload causes an error.
IMO this is wrong. Fields that genuinely affect only the startup ought to be freely changeable. Otherwise you might change the on-di...Currently (if the docs are to be believed) an attempt to change this field on reload causes an error.
IMO this is wrong. Fields that genuinely affect only the startup ought to be freely changeable. Otherwise you might change the on-disk config file intending to have this change at next restart, and then find that you cannot make other config changes.
However, ISTM that for this specific field, there is a more fundamental problem. This parameter is used for preemptive circuit constrution. Declaring a new set of ports for which we want to now preemptively build circuits seems like a meaningful thing to do at runtime. So, the parameter has the wrong semantics (and the wrong name).
Combining, during reload, a new set of configured ports with the ones discovered during runtime, is left as an exercise to the implementor. I think any plausible algorithm will do.
I am *not* tagging this as an API break, because we need to be able to evolve the config file without breaking changes. See also #285.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/177Recover from corrupted state or cache on startup.2023-06-13T17:50:00ZNick MathewsonRecover from corrupted state or cache on startup.When we start up, if we can't load our persistent state, we'll currently exit with an error. That's not good user experience: instead we should maybe move aside any broken/unreadable state files? Or perhaps we should ignore them and no...When we start up, if we can't load our persistent state, we'll currently exit with an error. That's not good user experience: instead we should maybe move aside any broken/unreadable state files? Or perhaps we should ignore them and not use persistent state? There are multiple possibilities here, and it's not obvious which is best.Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/94Stable, usable command-line interface.2024-02-19T18:31:52ZNick MathewsonStable, usable command-line interface.Before we can say that arti's ready for production, we need our command-line interface to be good enough for people to use, and we need to commit to supporting it.Before we can say that arti's ready for production, we need our command-line interface to be good enough for people to use, and we need to commit to supporting it.Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/702More unit tests for tor-ptmgr crate2023-02-27T12:00:40ZNick MathewsonMore unit tests for tor-ptmgr crateCurrent ptmgr unit test coverage is around 38%. Let's get that increased :)Current ptmgr unit test coverage is around 38%. Let's get that increased :)Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/682Try to recover our unit test coverage post arti-1.1.02023-04-25T15:37:35ZNick MathewsonTry to recover our unit test coverage post arti-1.1.0With 1.1.0, our unit test coverage has dropped to 78.06%. This is the [lowest unit test coverage](https://gitlab.torproject.org/tpo/core/arti/-/wikis/ReleaseHistory) level on ANY release of arti that we have ever done: ouch!
It's time ...With 1.1.0, our unit test coverage has dropped to 78.06%. This is the [lowest unit test coverage](https://gitlab.torproject.org/tpo/core/arti/-/wikis/ReleaseHistory) level on ANY release of arti that we have ever done: ouch!
It's time to look at our [coverage results](https://tpo.pages.torproject.net/core/arti/coverage/unit/) and see where we need to write tests. Let's not scrimp here: our test coverage has saved us from bugs in the past!Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/681Resolve remaining comments from !901 and !9032023-02-27T12:00:34ZNick MathewsonResolve remaining comments from !901 and !903The reviews of !901 and !903 had some suggestions, mainly related to commenting and documentation. We should apply those before we forget about them entirely.The reviews of !901 and !903 had some suggestions, mainly related to commenting and documentation. We should apply those before we forget about them entirely.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/677More debug logs in pluggable transports2023-06-20T13:54:59ZNick MathewsonMore debug logs in pluggable transportsSpecifically, it would be good to have more debugging logs throughout the PT lifecycle, and to have trace logs for every step of the way along making a connection, negotiating with the proxy, etc. I have some `stashed` junk that I used ...Specifically, it would be good to have more debugging logs throughout the PT lifecycle, and to have trace logs for every step of the way along making a connection, negotiating with the proxy, etc. I have some `stashed` junk that I used in debugging, but it isn't production quality.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/674pt transports configuration is not properly tested2023-06-20T13:51:20ZIan Jacksoniwj@torproject.orgpt transports configuration is not properly testedWe don't test an entry in `[[bridges.transports]]`.
See `arti/crates/arti/src/cfg.rs`, `TODO` near `CONFIG_KEYS_EXPECT_NO_EXAMPLE`We don't test an entry in `[[bridges.transports]]`.
See `arti/crates/arti/src/cfg.rs`, `TODO` near `CONFIG_KEYS_EXPECT_NO_EXAMPLE`Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/665Reject overlapping pluggable transport protocol configs2023-01-18T14:51:36ZetaReject overlapping pluggable transport protocol configsThe following discussion from !886 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/886#note_2856541):
> Sorry about that. Please file a ticket along the lines...The following discussion from !886 should be addressed:
- [ ] @Diziet started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/886#note_2856541):
> Sorry about that. Please file a ticket along the lines of "we should reject overlapping pt protocol configs" and feel free to assign it to me.Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/651Basic acceptance testing for 1.1.0 deliverables2023-01-10T18:23:24ZNick MathewsonBasic acceptance testing for 1.1.0 deliverablesHere's what we should test to make sure that 1.1.0 behaves as advertised.
Please add more cases as needed. In each case, it would be nice to have integration testing, but we should at a minimum test these cases by hand.
## Successful ...Here's what we should test to make sure that 1.1.0 behaves as advertised.
Please add more cases as needed. In each case, it would be nice to have integration testing, but we should at a minimum test these cases by hand.
## Successful cases
* [x] Configure Arti with a single bridge, not using a pluggable transport.
* [x] Configure Arti with a single bridge, using obfs4. (#332)
* [x] Configure Arti with a single bridge, using snowflake. (#333)
* [ ] Configure Arti with multiple bridges, including a few nonexistent ones.
In each of the successful cases, we should:
* Observe that we can browse and download successfully.
* Observe that the log messages are reasonable-looking at level `info` and higher.
* Observe (using instrumentation, `lsof`, `tcpdump`, or similar) that Arti is only connecting as it is told.
You can get bridges from `bridges.torproject.org`.
## Failing cases
* [ ] Configure arti to use bridges, using only a single nonexistent bridge.
* [ ] Configure arti to use bridges, using multiple nonexistent bridges.
In the failing cases we should:
* Observe that the log messages are reasonable-looking at level `info` and higher.
* Observe (using instrumentation, `lsof`, `tcpdump`, or similar) that Arti is only connecting as it is told.
## Complex cases
* [ ] Configure a list of bridges, and turn enable_bridges on and off. Make sure that Arti behaves correctly.Arti 1.1.0: Anticensorship readyhttps://gitlab.torproject.org/tpo/core/arti/-/issues/629bridge descriptor download parameters should be configurable2022-12-12T18:13:36ZIan Jacksoniwj@torproject.orgbridge descriptor download parameters should be configurable`BridgeDescMgr` is configurable via a `struct BridgeDescDownloadConfig`. But right now the only way to construct one of those is its `Default` impl. Instead, this should be configurable via or derivable from something that appears, eve...`BridgeDescMgr` is configurable via a `struct BridgeDescDownloadConfig`. But right now the only way to construct one of those is its `Default` impl. Instead, this should be configurable via or derivable from something that appears, eventually, in `TorClientConfig`.
Open questons:
* Should this be part of `DownloadSchedule` (`[download_schedule]` config section) or part of `[bridges]` ?
* Do we want a way for the user to specify `parallelism` in one place for both directory downloads and bridge downloads - or are these different things that they ought not to be mixed up this way?
* Same question for `BridgeDescDownloadConfig.retry` vs `DownloadScheduleConfig.retry_*`?
When this is decided the actual implementation should be reasonably obvious.Arti 1.1.0: Anticensorship readyIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/25438Use Locked Prefs2023-10-09T16:59:47ZTom Rittertom@ritter.vgUse Locked Prefshttps://bugzilla.mozilla.org/show_bug.cgi?id=440908 adds support for locked prefs, which are set during build and cannot be changed.
If that doesn't wind up in 60, I think it should be backported, and taken advantage of.
We can lock at...https://bugzilla.mozilla.org/show_bug.cgi?id=440908 adds support for locked prefs, which are set during build and cannot be changed.
If that doesn't wind up in 60, I think it should be backported, and taken advantage of.
We can lock at least the proxy settings. We could consider locking FPI and Fingerprinting settings, but I'm not sure those would be appropriate to lock.Sponsor 131 - Phase 3 - Major ESR 102 Migration