This will enable hidden services to send `RENDEZVOUS1` messages to the
`N`th hop of the circuit rather than the `N + 1`th virtual one (which
can only used after the client and service have completed the
introduction handshake).
This also deprecates `start_conversation_last_hop`.
Closes#959
`HopNum` will be used in `ClientCirc`'s public API when we refactor
`ClientCirc::start_conversation_last_hop` to use the provided hop rather
than always using the last one.
This `sleep` is to give the reactor task a chance to process the
`AwaitIncomingStream` message. With an 100ms, this test sometimes fails
because for some reason the reactor doesn't get a chance to process the
`AwaitIncomingStream` control command before the BEGIN cell from the
client task is received. This bumps the sleep time to 200ms for now
(TODO: follow-up with an MR with a less flaky approach).
While trying to repro the issue, I found another corner case for which
I've added a TODO HSS.
This updates the reactor to call the incoming stream handler even for
streams for which we have a stream map entry of `EndSent`. If we've
sent an END message for a stream but have not yet received an END
message back from the other party, but we later receive a BEGIN from
them, it is safe to assume we cam remove the stream from the stream map
and handle the new incoming stream request.
This adds a new `AwaitIncomingStream` control message for registering an
interest in an incoming stream.
This also adds a `ClosePendingStream` control message for explicitly
closing a stream with a given END message (needed for implementing
`IncomingStream::reject`).
This adds a new `add_ent_with_id` function for adding a new entry to the
`StreamMap`. The existing `add_ent` function auto-generates a new stream
ID, which is not good if we're a hidden service, as stream IDs are
supposed to be chosen by the OP (client). When accepting a new stream,
services, exit relays, and dir auths need to use the stream ID received
in the BEGIN cell (instead of generating a new stream ID).
When accepting a new stream, hidden services, exit relays and dirauths
don't wait for a `CONNECTED` cell from the initiator.
This commit adds constructors for building `DataStream`s and
`DataCmdChecker`s that can immediately receive data cells (and don't
expect to receive `CONNECTED` cells at all).
The build found a stale private doc comment as well as an exception
that needed to be made in check_doc_features.
The check_doc_features change solidifies a decision that things marked
with cfg(fuzzing) aren't part of the documented API.
This function isn't actually needed (it's not the responsibility of
`KeyType` to encode keys).
This commit also rewrites `ArtiNativeKeystore::insert` to use the new
`as_ssh_keypair_data` function instead of `to_ssh_format`.
The `EncodableKey::to_bytes` function didn't make much sense, because
not all keys have a canonical byte representation.
This commit replaces `EncodableKey::to_bytes` with
`EncodableKey::as_ssh_keypair_data`. In the future, `EncodableKey` will
grow functions for encoding keys in other storage formats too.
Closes#965
There are some places we might improve this, maybe testing more data
types and shapes. This patch just makes the minimal changes necessary
to get it working: adds allocation logic to the fuzzer itself,
and adds visibility for the bucket_array::mem interface.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
In response to review feedback, explain that 'seed' here is more
for compatibility and convenience and not central to our goal of
fuzzing the program generator.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Fuzz testing for HashX. Uses a hook into the pseudorandom number
stream to test the program generator deeply on input that can
be mutated by the fuzzer. Confirms program generation by running
a small number of arbitrary test hashes, so we don't need to
understand the implementation-specific program format to test the
program generator.
We test four implementations in parallel this way, the compiled and
interpreted implementations included in both this crate and c-tor.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
The solve tests are all tunable so that we can balance execution time
with test coverage. A longer solve will test more random programs and it
will test more of the nonce increment function, minor benefits at the
cost of much more CPU.
The starting nonce in solve_effort1k_aa_41_01 was set so that we would
exercise a rollover in bit 7 of the nonce increment before the full
width rollover, but this wasn't a particularly helpful place to test
and certainly not worth the 13+ seconds it takes on my machine.
This patch bumps the starting nonce to a value much closer to the
target, and still including the full-width rollover.
Brings solve_effort1k_aa_41_01 down from 13.2 seconds to 0.5 sec for me.
For ticket #991
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This test had one large function for all the verifies and one for all
the solves. The solve test was slow enough to be a bottleneck,
documented in ticket #991.
This patch splits the existing tests up in to one labeled function per
solve or verify configuration.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Propagates this setting from the outer Cargo.toml to the new
benchmark crates, since they no longer get the setting by
being included in the main workspace.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
It might be useful to keep these locked down for benchmark
reproducibility. Currently the hashx and equix crates are
fully separate.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This is a small batch of improvements for the equix and hashx
benchmarks. The headline feature is that we are now including
the C implementations (slightly modified from tevador's, hosted
as part of c-tor) and using them in apples-to-apples comparisons.
Minor features:
- Benchmarks moved to new nested crates, preventing their
dependencies from spilling into the main workspace build.
- Tests are now grouped
- We also test the performance of memory reuse where possible
- Code cleanup for per-runtime options
These benchmark builds will now automatically pull in the c-tor
git repo and build portions of it with a Rust wrapper. This uses
the 'cc' and 'bindgen' crates, so it requires a C compiler and
libclang on the host system.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Gabriela Moldovan
Nick Mathewson
Micah Elizabeth Scott
Ian Jackson