| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will suffice to bypass the reactor when we're dealing with
an unmanaged pluggable transport.
Closes #755.
|
| |
|
|
| |
Now that it's extracted, we can remove a mut and some nesting.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is based on an original branch by Trinity. Instead of its
original approach, which used an enum in the configuration to
distinguish managed from unmanaged transports, this branch uses
builder validation function to ensure that incompatible options
aren't used together. Doing the lets us generate better error
messages.
Thanks: trinity-1686a <[email protected]>
|
| |
|
|
| |
We're going to start using this type for _every_ kind of transport.
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes #949.
|
| |
|
|
| |
Closes #950.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
These are also based on temporary logs that I added locally while I
was hunting bugs.
Also part of #677.
|
| |
|
|
|
|
|
| |
If we don't do this, then snowflake's stdin will get closed and
it will exit immediately.
Found while investigating #333.
|
| | |
|
| |
|
|
| |
This is used exclusively by the reactor.
|
| |
|
|
|
| |
We may want to change this later, but this API is in a low level
crate, so this isn't a blocker.
|
| |\
| |
| |
| |
| |
| |
| | |
ptmgr: Do not construct an empty select_all future.
Closes #672 and #670
See merge request tpo/core/arti!907
|
| | |
| |
| |
| |
| |
| | |
Closes #670.
Closes #672.
|