| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
More documentation about refining build process and getting help
Closes #277
See merge request tpo/core/arti!259
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Explain how to report bugs and how get accounts on the bugtracker;
add link to the troubleshooting document.
Part of #277
|
| | | | |
| | | |
| | | |
| | | | |
Part of #277
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Error plan
See merge request tpo/core/arti!257
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Refactor our Runtime implementations to allow replacement parts
Closes #255
See merge request tpo/core/arti!251
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will make it easier to implement them using some other TLS
provider as well, without having to duplicate all of our code.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | | |
StreamPrefs: rename from ConnectPrefs
See merge request tpo/core/arti!256
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In line with the rest of the renaming.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/256#note_2771617
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Placates rustfmt
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Provide isolate-all-streams function
Closes #279
See merge request tpo/core/arti!252
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/252#note_2771291
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/252#note_2771289
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
No functional change.
This will grow a new variant shortly.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
CONTRIBUTING: Document how to build the docs
See merge request tpo/core/arti!255
|
| |/ / / / /
| | | | |
| | | | |
| | | | | |
Eventually we may need a separate HACKING.md
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Refactor, fix, test PathConfig type
See merge request tpo/core/arti!254
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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. :)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| |/ / / / /
| | | | |
| | | | |
| | | | | |
This was added by mistake.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Provide TorClient::set_default_prefs and clone_with_prefs
Closes #290
See merge request tpo/core/arti!250
|
| | | | | | | |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/250#note_2771239
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This may save quite a bit of copying. The callees don't need to copy
the whole struct; they copy the bits they need.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
These aren't flags. Eg, there's an isolation token in there.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
with_coverage: Allow toolchain selection.
See merge request tpo/core/arti!253
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There's some kind of bug in nightly that (for me) keeps grcov from
generating correct results. Instead, it misses some crates entirely.
No trouble, though: I can just use an older nightly until they get
this issue fixed!
This patch makes using a different version of nightly possible with
a new RUST_COVERAGE_TOOLCHAIN environment variable.
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Adopt an initial MSRV policy.
Closes #283
See merge request tpo/core/arti!247
|
| | | |/ /
| |/| |
| | | |
| | | | |
Closes #283.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/249#note_2771025
It doens't really handle it.
|
| | |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Discovered by clippy
|
| |/ / |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|