mirrors/arti.git/crates/tor-proto/src/crypto/handshake, branch ios-sqlite-hacks

Run maint/add_warning to add lint block everywhere

2023-08-23T09:34:00Z

Run maint/add_warning to actually apply new lint allows

2023-07-10T12:49:51Z

Back down x25519-dalek to 2.0.0-pre.1 from 2.0.0-rc.2

2023-06-27T17:55:24Z

========================= Notes from nickm: (This differs from pinkforest's original MR: It removes the Cargo.lock changes and the version bump on tor-llcrypto.) Minimal Cargo.lock changes from downgrade. (These are exactly those changes generated by running "build" and "test".) There are several reasons to do this: * It's best to bump all of our dalek dependencies at once to rc.3 or later, rather than the piecemeal approach we've been stuck with so far. * We don't want to do this bump right now, since there are some tricky questions about clamping we need to figure out (see #808), and we need to make sure we get them right, and we're in a distracted this week. * We _do_ need to move away from 2.0.0-rc.2 right now, since it was causing a failure in `cargo install arti`, and then it got yanked. Thanks to pinkforest for helping us out here and explaining all of this! Fixes #926. Commit-edited-by: Nick Mathewson

proto: Put client and service hs_ntor behind individual features

2023-06-21T19:06:20Z

This lets us keep the service-side hs-ntor handshake experiemental for now.

proto: Resolve some hs_ntor "TODO HS" comments.

2023-06-21T18:58:54Z

Lower tor-proto::util::ct::lookup to tor-llcrypto

2023-06-16T16:24:05Z

This is mostly code movement; you may want to review it with `--color-moved`. I'm doing this so we can also use the function in netdoc for looking up hsdesc authentication.

proto: Add a commment about a problem in my hs_ntor plans.

2023-06-12T17:15:59Z

I am pretty sure that C tor works around this somehow; we should figure out how!

proto: code movement and reindentation in hs_ntor

2023-06-12T17:15:59Z

proto: Remove now-unused hs_ntor APIs

2023-06-12T17:15:59Z

proto: refactor hs_ntor to reuse state.

2023-06-12T17:15:59Z

We want the ability to send the same handshake request in parallel on multiple introduce circuits. This implies encoding the client handshake more than once. (Sadly we can't _actually_ do this in the protocol as it stands, since the onion service can use a separate KP_hss_ntor for each introduction point; I'll add a comment to that effect later.)