summaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
* | Remove a now-incorrect comment in tor-proto.Nick Mathewson2022-01-261-3/+0
| |
* | Remove misspellings of "rusttls".Nick Mathewson2022-01-261-2/+2
| |
* | More comments on the limitations of tor-rtcompat's TLS APINick Mathewson2022-01-252-3/+29
| | | | | | | | | | Also, more comments on why these limitations are safe within the context of Tor, but you wouldn't want to use them elsewhere.
* | Comment-only: document sni_hostname more.Nick Mathewson2022-01-251-3/+5
| | | | | | | | | | Previously we expected the reader to automatically know why it was called "SNI", which really isn't fair.
* | Refactor native_tls usage into its own moduleNick Mathewson2022-01-257-230/+130
| | | | | | | | | | This change uses the async-native-tls crate for everything, and deletes some duplicated code.
* | tor-rtcompat: Add support for rustls.Nick Mathewson2022-01-258-9/+461
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on @janimo's approach in !74, but diverges in a few important ways. 1. It assumes that something like !251 will merge, so that we can have separate implementations for native_tls and rustls compiled at the same time. 2. It assumes that we can implement this for the futures::io traits only with no real penalty. 3. It uses the `x509-signature` crate to work around the pickiness of the `webpki` crate. If webpki eventually solves their [bug 219](https://github.com/briansmith/webpki/issues/219), we can remove a lot of that workaround. Closes #86.
* | Add a C program to make Tor-style X509 link certificatesNick Mathewson2022-01-241-0/+159
| | | | | | | | | | We should never use this for anything but making the testing certificates we use for making sure our TLS implementation works.
* | Merge branch 'ticket255' into 'main'eta2022-01-249-45/+339
|\ \ | | | | | | | | | | | | | | | | | | Refactor our Runtime implementations to allow replacement parts Closes #255 See merge request tpo/core/arti!251
| * | Refactor Runtimes to use separate TLS implementations internally.Nick Mathewson2022-01-198-45/+135
| | | | | | | | | | | | | | | This will make it easier to implement them using some other TLS provider as well, without having to duplicate all of our code.
| * | Add a macro to help with opaque Runtime wrappers.Nick Mathewson2022-01-192-0/+70
| | | | | | | | | | | | | | | | | | | | | We're soon going to have our different Runtime types be built as CompoundRuntime instances. We don't want to expose that detail, though, so we'll use this macro to make them implement the right traits.
| * | Add a CompoundRuntime type for runtime construction.Nick Mathewson2022-01-192-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This type can solve two problems at once. First, it lets users replace parts of an existing runtime implementation without replacing the whole thing. For example, you can use it to override your TcpProvider implementation to solve problems like #235. Second, we can use it internally to tor-rtcompat to define Runtimes piece-by-piece. Mostly we'll use this to separate our Tls implementations from our implementations of the rest of the Runtime.
* | | Rename TorClient::set_stream_prefsIan Jackson2022-01-211-2/+2
| | | | | | | | | | | | | | | | | | | | | In line with the rest of the renaming. As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/256#note_2771617
* | | StreamPrefs: Re-alphabetise imports following renameIan Jackson2022-01-211-1/+1
| | | | | | | | | | | | Placates rustfmt
* | | StreamPrefs: rename from ConnectPrefsIan Jackson2022-01-215-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The docs even say this is about stream. As @nickm writes in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/252#note_2771289 we generally call end-to-end connections that are tunneled over Tor "Streams" to distinguish them from everything else in the Tor protocols that could possibly be called a "Connection". That seems to apply here too.
* | | Merge branch 'always-isolate' into 'main'Ian Jackson2022-01-201-4/+58
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Provide isolate-all-streams function Closes #279 See merge request tpo/core/arti!252
| * | | isolation: Rename isolate_every_stream from ..._connectionIan Jackson2022-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/252#note_2771291
| * | | isolation: Rename (internal) EveryStream enum variantIan Jackson2022-01-201-3/+3
| | | | | | | | | | | | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/252#note_2771289
| * | | isolation: Much better wording for always isolate settingNick Mathewson2022-01-201-1/+6
| | | |
| * | | isolation: Provide isolate-every-connection optionIan Jackson2022-01-201-0/+16
| | | |
| * | | isolation: Provide new_isolation_group methodIan Jackson2022-01-201-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the usual case, set_isolation_group is awkward. This is perhaps slightly duplicative with TorClient::isolated_client(). If so then perhaps the *latter* should be abolished.
| * | | isolation: Refactor to introduce a bespoke enumIan Jackson2022-01-201-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | No functional change. This will grow a new variant shortly.
* | | | Test for PathConfig::at_least_as_permissive_as().Nick Mathewson2022-01-201-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | This is totally not just an exercise to get combined test coverage for tor-circmgr over 90% because I needed something to do that wouldn't distract anybody else. :)
* | | | Rename PathConfig::more_permissive_than()Nick Mathewson2022-01-202-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Since it implements a "<=" type relationship, it should be called "at_least_as_permissive_as()." Since it's a crate-private function, the long name isn't too bad.
* | | | Remove "self" arg from PathConfig::builder()Nick Mathewson2022-01-201-1/+1
| | | | | | | | | | | | | | | | This was added by mistake.
* | | | Merge branch 'stuff-prefs' into 'main'Nick Mathewson2022-01-202-21/+62
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | | | | | | | | | Provide TorClient::set_default_prefs and clone_with_prefs Closes #290 See merge request tpo/core/arti!250
| * | | connection preferences: Make `set_default_prefs` private for nowIan Jackson2022-01-201-1/+4
| | | |
| * | | connection preferences: Make `clone_with_prefs` must_useIan Jackson2022-01-201-0/+1
| |/ / | | | | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/250#note_2771239
| * | connection preferences: Provide `clone_with_prefs` methodIan Jackson2022-01-191-0/+10
| | |
| * | connection preferences: Provide `set_connect_prefs` methodIan Jackson2022-01-191-6/+22
| | |
| * | connection preferences: Take ConnectPrefs by referenceIan Jackson2022-01-192-12/+12
| | | | | | | | | | | | | | | This may save quite a bit of copying. The callees don't need to copy the whole struct; they copy the bits they need.
| * | connection preferences: Rename variable and docs to not say "flags"Ian Jackson2022-01-191-12/+12
| | | | | | | | | | | | These aren't flags. Eg, there's an isolation token in there.
| * | isolation: Document orthogonality of isolated_client and isolation_groupIan Jackson2022-01-191-0/+11
| | |
* | | clippy: Rename a `decode_chanmsg` from `handle_`Ian Jackson2022-01-192-4/+4
| | | | | | | | | | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/249#note_2771025 It doens't really handle it.
* | | handshake: Use read_exact, not read and checking lenIan Jackson2022-01-191-3/+7
|/ / | | | | | | | | | | | | | | | | read_exact has a loop in it, which we need. This means we end up separating the two sites that generate the "not a relay" error, so we need to fish out the error construction. As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/249#note_2771023
* | clippy: Rename a `from_foo` method that doesn't do conversionIan Jackson2022-01-193-5/+7
| |
* | Fix two bugs related to incomplete read/writeIan Jackson2022-01-191-3/+3
| | | | | | | | Discovered by clippy
* | clippy: Suppress a warningIan Jackson2022-01-191-0/+3
| |
* | Merge branch 'bootstrap_reporting'Nick Mathewson2022-01-1911-54/+1208
|\ \
| * | bootstrap reporting: Documentation fixups from review.Nick Mathewson2022-01-192-2/+14
| | |
| * | Integrate status information at arti-clientNick Mathewson2022-01-182-40/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit combines status update information from tor-dirmgr and tor-chanmgr in the arti-client crate, so that the user can get to it; it represents a high-level view of the client's ability to reach the network and route traffic. I have omitted the tor-circmgr support for now; it's mostly not needed. At present it's not so useful, since there's no way for a client to get a TorClient that _isn't_ completely bootstrapped, and therefore there's no way to actually watch these events until they're no longer interesting. That should change with arti#293. This is part of #96.
| * | tor-chanmgr: Add bootstrap/status reporting.Nick Mathewson2022-01-184-5/+523
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The information is pretty basic here: we use "have we been able to connect/TLS-handshake/Tor-handshake" as a proxy for "are we on the internet? Are we on a reasonably unfiltered part of the internet?" Eventually we'll want to make the information gathered and exported more detailed: I've noted a few places in the code. For now, however, this is about as good as C Tor does today, and it should be a good starting point. This uses a slightly different design from tor-dirmgr. Instead of exporting an entire state structure via `postage::watch`, it exports only the parts of that structure which the user is supposed to read. I think that's more reasonable in this case because most of the possible internal transitions in the tor-chanmgr state don't cause a change in the exposed status.
| * | tor-dirmgr: Create a bootstrap-status exporting mechanism.Nick Mathewson2022-01-185-9/+591
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The interface is similar to the one exposed by `arti-client`: it internally uses postage::watch to give a series of events showing when a bootstrap status is changing. Thanks to the existing state/driver separation in the DirMgr design we don't need much new logic: each download state needs to expose (internally) how far along it is in its download, which the bootstrap code passes to the DirMgr if it has changed. I believe that in the long run, we'll probably want to expose more (or different) information here, and we'll want to process it differently. With that in mind, I've made the API for `DirBootstrapStatus` deliberately narrow, so that we can change its of its internal later on without breaking code that depends on it. (The information exposed by this commit is not yet summarized in `arti-client`.) Part of #96.
* | | Merge branch 'eta/292-2' into 'main'eta2022-01-191-20/+95
|\ \ \ | | | | | | | | | | | | | | | | arti-bench: add concurrency, write benchmark results out to JSON See merge request tpo/core/arti!243
| * | | arti-bench: add concurrency, write benchmark results out to JSONeta2022-01-181-20/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now conduct benchmark tests with multiple concurrent streams (by default; this is configurable by passing `-p` to `arti-bench`). Currently, these results just get "flattened" for the purposes of statistical analysis (as in, results_raw contains the results of each connection's timing summary, across all benchmark runs). This might be something we wish to change in future. The stats summary now also records "best" and "worst" values for each metric, to give a rough idea of the range of values encountered. Additionally, we now support writing the benchmark results out to a JSON file. A future commit may integrate this with CI, so that we have benchmark results for every commit as a build artefact. (some documentation was also fixed) part of arti#292
* | | | Merge branch 'correct-cache' into 'main'eta2022-01-191-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | Put our cache files in the right place. Closes #297 See merge request tpo/core/arti!244
| * | | Put our cache files in the right place.Nick Mathewson2022-01-181-1/+1
| |/ / | | | | | | | | | | | | | | | | | | This resolves a copy-and-paste error where we were putting everything in our state directory. Closes #297.
* | | Merge branch 'eta/292-1' into 'main'eta2022-01-142-30/+172
|\ \ \ | |/ / |/| | | | | | | | arti-bench: add support for multiple samples & averaging See merge request tpo/core/arti!240
| * | arti-bench: add support for multiple samples & averagingeta2022-01-142-30/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now do multiple samples (configurable; default 3) per type of `arti-bench` benchmark run, and take a mean and median average of all data collected, in order to hopefully be a bit more resilient to random outliers / variation. This uses some `futures::stream::Stream` hacks, which might result in more connections being made than required (and might impact the TTFB metrics somewhat, at least for downloading). Results now get collected into a `BenchmarkResults` struct per type of benchmark, which will be in turn placed into a `BenchmarkSummary` in a later commit; this will also add the ability to serialize the latter struct out to disk, for future reference. part of arti#292
* | | Merge branch 'bootstrap_reporting_api' into 'main'Nick Mathewson2022-01-134-1/+222
|\ \ \ | |/ / |/| | | | | | | | Implement the basics of a bootstrap-status API. See merge request tpo/core/arti!237
| * | Implement the basics of a bootstrap-status API.Nick Mathewson2022-01-134-1/+222
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of a this API is to tell the user how far along Arti is in getting bootstrapped, and if it's stuck, what it's stuck on. This API doesn't yet expose any useful information: by the time it's observable to a client, it's always "100% bootstrapped." But I'm putting it in a MR now so that we can review the basic idea, and to avoid conflicts with later work on tickets like #293 and #278. This is part of #96.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 21:05:35 +0000