| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
If and when we implement this, it will likely be different;
arti#868 has some thoughts on the implications.
|
| |/ /
| |
| |
| |
| | |
These will have different implementations soon; this is a more
logical place for them.
|
| | |
| |
| |
| |
| |
| | |
This warning shows up when running `cargo +nightly doc`.
Apparently nightly doesn't like it when we have elided a lifetime
that has a perfectly good name.
|
| | |
| |
| |
| | |
Mark it no longer experimental, but part of full. And document it.
|
| | |
| |
| |
| | |
Mark it no longer experimental, but part of full. And document it.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
And document the Cargo features.
This compiles in the memquota support for people who depend directly
on tor-memquota. But all our in-tree dependencies turn off default
features, so this doesn't have any effect for in-tree crates.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Sort them alphabetically.
Use the bullet point style we see elsewhere.
Use the same headings as elsewhere.
|
| | | |
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2561#note_3097443
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2561#note_3097442
|
| | |
| |
| |
| |
| | |
Work around awkward cargo behaviour and allow us to more reliably test
disabled features, even if they're enabled by default at lower levels.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new feature lets us provide the "enable these options which are
needed to make the tests pass" featrure, which is different for each
of the afflicted crates. Then we can test these crates
tor-hsservice
arti
arti-client
which minimal features.
This will be important in a moment, as we're going to want to be
relying on actually minimal features tests in arti cfg.rs.
|
| |\ \
| | |
| | |
| | |
| | | |
memquota: Fix account lifetime bugs, and arrange to test mq in shadow
See merge request tpo/core/arti!2560
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Promote the associated comments.
As suggested here:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2560#note_3097188
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2560#note_3097189
|
| | | |
| | |
| | |
| | |
| | | |
These errors aren't necessarily memory pressure. They can occur due
to bugs, and during teardown.
|
| | | |
| | |
| | |
| | |
| | | |
This detects the bugs I have just fixed - in Shadow tests with the
feature enabled and a (large) limit set.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The DataStream is sometimes disassembled, eg by split. When that
happens, the StreamAccount would be dropped - and that was the only
strong reference.
Put a StreamAccount in each of the pieces, instead of just in the
combined DataStream struct.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We need the mq account for the stream not to collapse. The
ResolveStream object needs to contain a strong reference to it.
Have begin_stream_impl return the StreamAccount, rather than taking it
as a parameter. That makes this bug a little more obvious. It also
centralises the StreamAccount creation.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Now that it doesn't call CircuitAccount::new() it has no error paths,
and clippy demands we remove the Result, so it must once again become
infallible.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We foolishly made *two* CircuitAccounts, one of which gets immediately
dropped. But we need to hold onto the account somewhere, because an
mq_queue doesn't keep the account alive.
Otherwise everything breaks when mq tracking is enabled.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
general::SocketAddr: Say "inet" rather than "tcp"
Closes #1701
See merge request tpo/core/arti!2554
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
"inet" makes more sense, since in principle these can also be used
for udp, etc.
Also making a corresponding change in rpc-connect-sketch.md,
which uses this format.
Closes #1701.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Remove an obsolete TODO
See merge request tpo/core/arti!2562
|
| | | |/ /
| |/| |
| | | |
| | | | |
This *is* in tor-async-utils :-).
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Move crates to crates to slotmap-careful
Closes #1531
See merge request tpo/core/arti!2530
|
| | | | | | |
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | | |
tor-proto: Reinstate circuit hop check in test_create()
See merge request tpo/core/arti!2546
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix typo in arti-rpcserver auth.rs comment
See merge request tpo/core/arti!2558
|
| | | |/ /
| |/| | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Our spec says that when the RPC client has said "I require you to have
feature X" and we don't have it, we need to include the feature(s)
we don't have in an `rpc:unsupported_features` field of our error.
Also, add an integration test for this behavior.
Closes #1662
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In older versions of the rpc spec, this field held a serialized
version of the Arti error object. That's no longer the design: now
it provides a way for specific errors to include extra, specified,
machine-readable data. For more information see the section
"Errors" in rpc-meta-draft.md
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
These are not regular ErrorKinds, since they can never occur in an
error that's meant to be returned from a Rust API like
`arti-client`. Instead, they only exist for errors returned from
RpcError.
(I can't find the place where we discussed this previously, but the
rationale is that if an ErrorKind never makes sense in response to
something that the user does from Rust, we should never have that be
an ErrorKind. The fact that the removed kinds do not actually
appear outside the RPC system suggests that this is reasonable.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I'm about to remove HasKind from InvokeError, which would otherwise
break this code.
These errors are all in fact internal errors, since in this context
they can only stem from incorrectly formed calls to
`invoke_special_method`.
|
| | | | |
| | | |
| | | |
| | | | |
In some cases, the tor_error::ErrorKind names were nicer.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We'll use this to make RpcErrors directly, without having to go
through an error that implements HasKind.
Later, we'll add the ability to set the `data` fields on an RpcError.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This change will let us start removing the not-entirely-logical
`Rpc.*` variants from tor_error::ErrorKind.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This is about to be a public competitor with tor_error::ErrorKind.
|
| | | | | |
|