mirrors/arti.git/crates/tor-proto/src/circuit.rs, branch arti-v0.0.3

ClientCirc: change some methods to take &self

2022-01-07T18:55:26Z

Previously they took Arc, and then Self, but &self is perfectly fine here.

tor-circmgr: Remove Arc around ClientCirc

2022-01-07T18:19:20Z

See the new commentary text on `ClientCirc` for the rationale. Signed-off-by: Ian Jackson

Merge remote-tracking branch 'origin/mr/212'

2022-01-06T13:28:13Z

tor-circmgr: Don't clone parameters in create_chantarget()

2021-12-26T01:22:38Z

tor-proto: In begin_stream_impl(), if number of hops is zero, don't continue

2021-12-26T00:01:22Z

tor-proto: use const-time eq on sendme tags.

2021-12-16T16:06:30Z

There's no known attack here, but it's best practice to always compare digests using a constant-time comparison operator. This resolves an XXXX comment.

add semicolons if nothing returned

2021-11-25T13:20:37Z

Try to make the tor_proto::circuit::begindir test more reliable.

2021-11-23T15:50:20Z

I traced the problem here to the fact that sometimes "rx" in this test would be dropped before the test was done. When "rx" is dropped, the channel reactor shuts down, which in turn kills off the circuit reactor. This bug may exist in other cases in these tests. This patch may fix one case of #238.

Make unreliable tor-proto tests more reliable (arti#238).

2021-11-18T16:06:53Z

The `bad_extend_*` failures were caused by bad test code in `bad_extend_test_impl` that used `futures::join!`; this meant that the reactor could receive the `Extended2` cell before it actually got the `ExtendNtor` request, which caused it to get (quite rightly) confused and close the circuit. Spawning a background thread which has a short delay before sending the `Extended2` cell seems to have alleviated this problem. `new_circ_create_failure` is similar; I think the reactor was getting dropped before it had a chance to flush out its `CreateFast` cell properly, because it had already gotten the result back (since the test code sends it indiscriminately). This was "fixed" in much the same manner as the other test: making it wait a bit before sending the result cell back. There seem to be other tests that use `futures::join!` (like `begindir`?), and use similarly erroneous patterns; I haven't gotten any to fail reliably enough to be able to debug them, though.

Always use optimistic data for begindir connections.

2021-11-16T20:20:44Z

Closes #226.