| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Allow configurability on preemptive circuits
Closes #245
See merge request tpo/core/arti!164
|
| | |/ |
|
| |/
|
|
|
|
|
|
| |
We want to only use TODO in the codebase for non-blockers, and open
tickets for anything that is a bigger blocker than a TODO. These
XXXXs seem like definite non-blockers to me.
Part of arti#231.
|
| |
|
|
| |
This makes sure that we're checking for a nonzero port in all cases.
|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The new CircMgr::build_circuits_preemptively function actually causes
preemptive circuits to be built; it gets called from arti-client, like
the other daemon tasks the CircMgr has.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The sane_defaults() call is now the same as you get from a default
builder: by convention, we just call that method Default::default().
The with_directories() constructor makes more sense as a constructor
for the TorClientConfigBuilder than for TorClientConfig.
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | | |
(Also fix a couple of typos)
|
| | | |
| | |
| | |
| | |
| | | |
Make sure that we can change elements, and we can reconstruct builders
that give us the same thing.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
When we deserialize a configuration, we should reject unknown variables
(except when we have an explicit reason to allow them).
|
| | | |
| | |
| | |
| | | |
These don't need to be exposed any longer.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm still not 100% sure this is the right move: should we encourage
app developers to always pick their own directories? Or should we
make it easy for them to use, well, `sane_defaults`?
This patch takes the second approach.
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| |/
|
|
| |
Also fix some commonwealth spellings that had slipped in.
|
| |
|
|
|
| |
This should be ergonomic than having to construct every section of the
configuration separately.
|
| |
|
|
|
| |
Doing this is necessary for reconfiguration support, and will help a lot
with testing, too.
|
| |
|
|
|
|
|
|
|
|
| |
This patch makes sure that for every* config type we have, the defaults
you get from a Builder match those you get from Serde, and that both
match the value that you get from arti_defaults.toml. Later down the
line I'll be adding some tests to keep these in sync.
* StorageConfig still has no defaults of its own, since we aren't so
sure we want other applications to use Arti's directories by default.
|
| |
|
|
|
|
|
|
| |
Since these shell-variables are hardwired to use org.torproject.Arti as
the program name, it isn't appropriate to call them "app-specific".
If we someday reinstate APP_FOO, it should be based on a user-provided
application name.
|
| |
|
|
|
|
|
|
| |
In order to handle explicitly specified path buffers directly, we now
let CfgPath be either a string (that gets expanded) or a PathBuf
(that doesn't).
This simplifies TorClientConfig::with_directories()
|
| |
|
|
| |
This will make it more convenient to reconfigure things.
|
| | |
|
| |
|
|
|
|
|
|
| |
Now every section that the two configuration objects share has the
same type and name. This should help us in documenting our configuration
in a way that doesn't confuse people.
There is still lots of API work to go.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
To do this at all neatly, I had to split out `tor-config` from
`arti-config` again, and putting the lower level stuff (paths,
builder errors) into tor-config. I also changed our use of
derive_builder to always use a common error type, to avoid
error type proliferation.
|
| | |
|
| |
|
|
|
| |
I'm about to make tor-config a higher-level module, so it can't be a
dependency for tor-config.
|
| | |
|
| |
|
|
|
| |
It seems like a good time to do this, before we add a zillion other
arguments to begin_stream.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the structs in `arti-client` have example code now, to give a
clearer idea of how they're used.
Annoyingly, a lot of the types exposed in `arti-client` are actually
re-exports, which makes documentation a bit harder: example code that
references other parts of `arti-client` can't actually be run as a
doctest, since the crate it's in is a dependency of `arti-client`.
We might be able to fix this in future by doing the documentation in
`arti-client` itself, but rustdoc seems to have some weird behaviours
there that need to be investigated first (for example, it seems to merge
the re-export and original documentation, and also put the re-export
documentation on the `impl` block for some reason).
For now, though, this commit just writes the docs from the point of view
of an `arti-client` consumer, removing notes specific to the crate in
which they're defined. It's not ideal, but at least the end user
experience is decent.
|
| | |
|
| | |
|
| |
|
|
|
| |
I'm not 100% sure this is better, but it might help the user
understand how Arti works a bit better.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This overhauls the top-level `arti-client` documentation significantly:
- the "Using arti-client" section walks the user through all of the
necessary steps to initiate a Torified TCP connection, and then
provides a code example
- this example is also available as `examples/readme.rs`; it's not run
as a doctest, since it involves connecting to Tor
- a "More advanced usage" subheading provides information about stream
isolation (and can potentially be used for other interesting
features once we get them).
- a new "Multiple runtime support" section was added to explain the
purpose and usage of the `tor-rtcompat` crate
- the section on design and privacy considerations was removed; this is
probably okay to keep in a README, but users of the crate aren't going
to be interested in this (at least I don't think)
(also, the doc comment for `arti_client::Error` was fixed to make actual
sense)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Now that we have two kinds of isolation tokens (those set on a
stream, and those set by the stream's associated TorClient), we
need a more sophisticated kind of isolation.
This fixes the bug introduced with the previous commit, where
per-stream tokens would override per-TorClient tokens.
|
| |
|
|
|
| |
When two TorClients are isolated, their streams shouldn't share
circuits, even though they share internal circuit and guard state.
|
| | |
|
