| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| | |
|
| |
|
|
| |
I have no idea why these became necessary.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
BridgeConfigBuilder is Serialize so this isn't making any new API
promises. Ideally we'd have getters like this everywhere.
|
| |\
| |
| |
| |
| |
| |
| | |
Stop unconditionally marking bridges as having dir info.
Closes #638
See merge request tpo/core/arti!1408
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
When we implemented bridges, we added code in 08473872abccf389 to
conditionally mark their directory info as present or not present.
But the we didn't remove the old code to mark them present
unconditionally!
Fixes #638.
|
| |/
|
|
|
| |
Currently we list an address for a bridge twice if it is listed both
in the bridge line and the bridge descriptor. That can't be right.
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
Clippy nightly now detects when you're calling into_iter() and
passing the result into something that accepts an
`impl IntoIterator`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many of these call sites would panic if, somehow, the upper bound was
zero. In most cases it is very complicated to see if whether this
could happen.
However, there is a better answer:
Durations are (conceptually) dense, so picking the closed set (which
includes its boundary) rather than the open one (which doesn't) will
make little practical difference.
So change four call sites to use `..=` instead of just `..`.
|
| |
|
|
| |
Closes #950.
|
| |
|
|
|
|
|
| |
This tries to flesh out some of the details for users who may be new
to bridges and PTs.
Closes #706.
|
| | |
|
| |
|
|
| |
Found by clippy nightly
|
| |
|
|
|
| |
I don't love this change, but apparently we are trying for
"consistency".
|
| |
|
|
|
|
|
|
| |
- We make the tor-guardmgr "We have found that {} is usable" line
include the word "guard", otherwise it doesn't appear very useful to a
user in safe logging mode, since the guard gets replaced with
[scrubbed].
- The "Actually got an end cell..." message is downgraded to DEBUG.
|
| |
|
|
|
|
| |
Now that we require a version of Rust that allows
`b.then_some(v)`, clippy complains about our use of
`b.then(|| v)`.
|
| | |
|
| | |
|
| |
|
|
|
| |
In both cases I think it's fine to panic; but it's best to do so
explicitly.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
This is in lieu of upgrading to the latest base64 crate, which has
a different API from the old one. Since we have to migrate either
way, we might as well use base64ct everywhere.
I don't think that most of these cases _require_ constant-time
base64, but it won't hurt.
|
| |\
| |
| |
| |
| | |
Add test lint blocks to all "mod test"
See merge request tpo/core/arti!937
|
| | |
| |
| |
| |
| | |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| |/
|
|
| |
Closes #589
|
| | |
|
| | |
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/904#note_2858480
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/904#note_2858479
|
| |
|
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/issues/668#note_2858220
This commit is difficult to split up.
The innards of BridgeAddr and PtTargetAddr are still a bit entangled.
|
| |\
| |
| |
| |
| | |
Add tests for a bunch of code in tor-linkspec
See merge request tpo/core/arti!867
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Support building without pluggable transports
Closes #649
See merge request tpo/core/arti!898
|
| | | |
| | |
| | |
| | | |
This is unused in bridgeless configs. Fixes a compiler warning.
|
| | | |
| | |
| | |
| | | |
We've revised this a few times; now it seems plausible.
|
| |/ / |
|
| | | |
|
| | |
| |
| |
| |
| | |
This machinery is a bit inelegant, but it is all confined to
be within the GuardMgr crate, so IMO it should be fine for now.
|
| |/
|
|
|
|
| |
Closes #627, again.
Closes #648.
|
| |\
| |
| |
| |
| | |
Make ChannelMethod non-exhaustive
See merge request tpo/core/arti!891
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Enums with variants conditional on cargo features must be
non-exhaustive, because cargo features are supposed to be additive,
meaning that enabling a feature (which might happen due to some random
distant thing) ought not to break things using that enum.
There were surprisingly few places to fix this.
|