| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
In !948 we renamed a couple of accessor functions, which is a
breaking change in `tor-cell`'s API.
In retrospect, perhaps we should have deprecated the old names and
added the new ones, so we wouldn't have to break the API. (This is
the only API break AFAICT since 1.1.0.)
|
| |
|
|
|
|
| |
These crates had API or behavior changes that may affect downstream
crates. Fortunately, they're all version 0.x, and don't need minor
bumps for this.
|
| |
|
|
|
|
|
| |
These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| | |
|
| |
|
|
| |
Fortunately, it adds very little to the arti-client API surface.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |\
| |
| |
| |
| | |
A few spelling fixes for bridgedescmgr code
See merge request tpo/core/arti!925
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
make use of 1.60 weak dependancy features
Closes #434
See merge request tpo/core/arti!920
|
| | | |
|
| |/
|
|
|
| |
We made this job easy this time around: by incrementing our MSRV, we
have forced ourselves to do at least a minor bump everywhere.
|
| |
|
|
|
| |
Since apparently it was possible to write all the other code without
moving it.
|
| | |
|
| |
|
|
|
|
|
|
| |
There's no harm in doing this, since we'll try to take ownership of
the state soon as soon as we use it: We just want to try early, so
that we'll get it before we decide that we're using bridges.
Fixes bug #669; bug introduced by !889.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This makes a `pt_state` directory inside .local/share/arti (or the
local equivalent), right next to our existing `state` dir.
Ideally we would use a separate directory for each PT, but we have a
very fuzzy "what is a specific PT" notion.
Closes #667
|
| |
|
|
|
|
|
|
| |
If support is available at compile-time, then we construct a PtMgr
and register it with the ChanMgr. We keep a handle to it ourself so
that we can reconfigure it as needed.
Closes #659.
|
| |\
| |
| |
| |
| | |
tor-basic-utils: DropNotifyWatchSender: use DropNotifyEofSignallable
See merge request tpo/core/arti!853
|
| | |
| |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/852#note_2854090
(ftaod, that is a different MR to this one)
|
| |\ \
| |/
|/|
| |
| | |
arti-client, tor-config: Remove stability warning from top-level docs
See merge request tpo/core/arti!878
|
| | |
| |
| |
| |
| |
| |
| | |
Ticket #285 is closed and most of this is stable now we think.
(There are still a couple of stability warnings for specific types in
tor-config, which aren't exposed at the arti-client level.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now parse the `bridges.enabled` BoolOrAuto, and the
`bridges.bridges` list.
The `bridges.bridges` list is Vec<()> in the builder, and Vec<Void> in
the built config. Ie, it is simply a count, and vanishes in the built
config.
But this count triggers us to try to call build(), to try to parse
bridges, and to try to set and honour the enablement boolean.
The result is that the type system now ensures that if bridges are
disabled, but specified (either by listing them in the config, or
writing `enabled=true`), we inevitably try to insist that we have a
non-empty Vec<Void>, which is of course impossible.
There will be a test case too for those who think this too abstract a
way to guarantee this property :-).
|
| |/
|
|
| |
By changing MultilineListBuilder.
|
| |\
| |
| |
| |
| | |
Fix warnings and breakage in nightly (2022-11-18 edition)
See merge request tpo/core/arti!872
|
| | |
| |
| |
| |
| | |
It looks like, despite a few false starts, they've got this warning
right; there weren't any false positives.
|
| | |
| |
| |
| |
| | |
This resolves some errors when building with `bridge-client` but not
with `--all-features`.
|
| | | |
|
| |/
|
|
| |
Doing this separately to make the next commit easier to read.
|
| |\
| |
| |
| |
| | |
tor-ptmgr: make configuration use builders, plumb into arti-client
See merge request tpo/core/arti!823
|
| | |
| |
| |
| |
| |
| |
| | |
This brings the draft configuration mechanisms in tor-ptmgr in line with
the config in other crates, using builders. It also plumbs the config
type through into the main `arti-client` config, and adds some example
lines to `arti-example-config.toml`.
|
| |/
|
|
| |
Fixes #636.
|
| | |
|
| |
|
|
| |
rustfmt only.
|
| |
|
|
| |
We'll need this shortly.
|
| |
|
|
| |
We'll need this shortly.
|
| |\
| |
| |
| |
| | |
Move guardmgr creation to arti-client, rather than within circmgr
See merge request tpo/core/arti!850
|
| | |
| |
| |
| | |
rustfmt only, broken out to ease review.
|
| | |
| |
| |
| |
| |
| |
| | |
Having this done within circmgr was irregular - most of our other key
buildup functions are done in TorClient::create_inner.
It is also inconvenient, as it buries the guardmgr within the circmgr.
|
| |\ \
| | |
| | |
| | |
| | | |
dirmgr: Expopse DirMgrStore
See merge request tpo/core/arti!851
|
| | |/
| |
| |
| |
| |
| |
| | |
Now the Store is constructed by arti_client, solving the problem
described here
https://gitlab.torproject.org/tpo/core/arti/-/issues/631#note_2853665
but in a different way.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is the validation which is called for by the documentation.
|