| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Removed unnecessary lint
|
| |\
| |
| |
| |
| | |
Added ConfigBuildError::MissingOneOf and did TODO
See merge request tpo/core/arti!4131
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
| |
This commit adds #[allow(clippy::string_slice)] to all functions in the
code where string slices are used, alongside a TODO comment.
We do this add the function header to have it consistent, as things like
expression based allow's are still experimental.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| |
|
|
|
|
|
| |
Previously the [channel] outbound_proxy setting was applied to Arti's
own direct connections but was not forwarded to managed PT processes.
https://spec.torproject.org/pt-spec/configuration-environment.html
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires the `TlsKeyAndCert` so be passed on the TLS acceptor
settings. We assume that `RelayIdentities` has this information.
The ChanBuilder::new() was getting a bit too convoluted and feature
gated to instead we introduce new_client() and new_relay() and remove
the need for `with_identities()`.
Because of this, the ChanMgr::new() now returns a `Result<>`.
Related to #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, we'll simply use `RelayInitiator` if the identity keys
(identities) struct is set.
This avoids the problem where someone could call outbound_chan_type() of
the ChanMgrConfig and get the wrong channel type if with_identities() is
set after.
This way, a single call, `with_identities()` is what will define the
outbound channel type so no chance of errors.
This also removes the cfg_if {} around the builder creation in a much
more simplified version.
Related to #1599
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This allows us to pass it to the ChanBuilder which will be able to use
this type for the outbound channels.
For now, we do this trick where if we have relay identities, we always
consider that all outbound channels will be RelayInitiator.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We'll rely on a RelayIdentities to pass in the right keys to the ChanMgr
instead of the entire KeyMgr.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Run maint/add_warning
|
| | |
|
| | |
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
|
|
|
| |
This is so a relay can build authenticated channels. Several keys/cert
are required for this that are within the key manager.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
See #2060.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big change across multiple crates since there isn't a good way
to break it up.
This changes the signature of `CfgPath::path` to:
```
pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> {
```
Making this change means that our global `CfgPathResolver` needs to be
stored in the 'arti-client' library instead of `tor-config-path`, and
must be passed through to anything that calls `path` to expand the
variables.
|
| | |
|
| |
|
|
|
| |
Also updated other packages to get `CfgPath` directly from
`tor-config-path' instead of 'tor-config'.
|
| |
|
|
| |
We have a ticket for this. But the ticket number was wrong, so fix that.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| |
|
|
|
| |
This conditionally compiles most of the code related to managed
transports.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Code that's related to managed transports has been moved to a new
'managed' module. This includes the PT reactor since it's not needed for
unmanaged transports.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a little nicer and more type-safe to work with than
`TransportConfig`. It would have been nice to change `TransportConfig`
directly instead, but it would slightly change arti_client's public API,
and would require an extra field in the `[[bridges.transports]]` toml
table.
|
| |
|
|
| |
See: tpo/core/arti#1488.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the PT STATUS handler to not require the presence of
the `TRANSPORT` field in the K/V line. This matches current behaviour of
C Tor and was requested by the Anti-censorship Team at an earlier point
to enable STATUS messages to work for situation where it's not transport
specific messages.
To avoid future issues, we simply ignore any required keys right now
even though TYPE is to be expected.
See: tpo/core/torspec#267
See: tpo/core/torspec!63
See: tpo/core/arti#1488
|
| |
|
|
| |
This commit is automatically generated.
|
| |
|
|
| |
(This is !Default, since there is no default TransportConfig.)
|