summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src
Commit message (Collapse)AuthorAgeFilesLines
* tor-proto: Add function for peeking at pending circ unique ID.Gabriela Moldovan2024-02-271-0/+5
| | | | | | | | | `tor_circmgr::Error::Protocol` will soon include an optional `UniqId`. Since `Protocol` errors can be caused by pending circuits, we need to be able to peek at their `UniqId`. Part of #1297
* tor-circmgr: Add a helper for displaying optional UniqIds.Gabriela Moldovan2024-02-271-1/+17
| | | | | | | | Some of the `tor_circmgr::Error` variants will include the `UniqId` of the corresponding circuit, so we'll need to be able to display it without the `Circ ` prefix. Part of #1297
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-132-11/+11
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* Merge branch 'send_incoming_request_failures' into 'main'gabi-2502024-01-172-30/+57
|\ | | | | | | | | | | | | Several clean-ups around failures in incoming stream request handlers. Closes #1190, #1189, and #1188 See merge request tpo/core/arti!1892
| * proto: Use log_ratelim to report problems delivering BEGIN messges.Nick Mathewson2024-01-171-3/+7
| |
| * Give an error on duplicate call to allow_stream_requests.Nick Mathewson2024-01-172-8/+2
| | | | | | | | Closes #1190
| * proto: Close circuit _intentionally_ when Request Sink is dropped.Nick Mathewson2024-01-172-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, it might be better to just un-register the IncomingStreamRequestHandler when the Receiver for the stream requests is dropped. However, there are two reasons not to do so: 1. It's tricky. We never actually poll on the corresponding Sink, so there isn't a place where the Reactor would expect to get a prompt notification of closure. We only find out that the Receiver has been dropped when an attempt to send on the Sink returns an `is_disconnected` error. 2. It's unnecessary. In the Tor protocols, once we have decided to accept incoming stream requests on a circuit, we want to continue to do so until one of the parties closes the circuit. I've documented this in several comments, in case whe want to get fancier in the future. Closes #1188.
| * proto: Send END when buffer of IncomingRequests is fullNick Mathewson2024-01-172-13/+14
| | | | | | | | Closes #1189.
* | Remove TODO for #1191Nick Mathewson2024-01-171-3/+0
|/ | | | | | The bug described here was already fixed as #1065 via !1681. Closes #1191.
* proto: Convert a TODO HSS to ticket #1191Nick Mathewson2024-01-101-1/+1
|
* Downgrade and convert TODO HSSs to #1190.Nick Mathewson2024-01-101-2/+2
| | | | | | | | | These are about making allow_incoming_streams give an error if a handler is already installed. I'm calling these non-MUST, since they don't affect the actual API here, and we already have comments telling you not to do that. We can add them later.
* Convert a TODO HSS about excessive BEGINs to #1189.Nick Mathewson2024-01-102-2/+3
|
* proto: Downgrade TODO HSS about HopNum in IncomingStreamRequestCommentNick Mathewson2024-01-102-5/+12
| | | | | | | These comments are about internal representations and future extensions. Also, add a fail-safe check to make sure that hop_num consistency is enforced.
* proto: Downgrade TODO HSS comments about hop lookupNick Mathewson2024-01-101-2/+2
|
* proto: Change some TODO HSS comments to refer to #1188Nick Mathewson2024-01-101-3/+3
|
* clippy: consequential rustfmtIan Jackson2024-01-021-8/+2
|
* clippy nightly: For now, locally allow blocks_in_conditionsIan Jackson2024-01-021-0/+1
| | | | | | Filed https://gitlab.torproject.org/tpo/core/arti/-/issues/1176 proposing a final fix.
* clippy: Use infallible callsIan Jackson2024-01-021-4/+2
| | | | Resolves clippy complaints about needless fallible conversions.
* clippy: Replace many calls to .get(0) with .first()Ian Jackson2024-01-022-2/+2
| | | | | FTR I don't think agree with clippy on this question, but then I often don't.
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-146-38/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is pure renaming, done automatically with rust-analyzer. Comment fixes and other cleanups will be in the subsequent commits. We're doing this renaming because we need a name for the combination of a `RelayMsg` and an `Option<StreamId>` that we use when we have a `RelayMsg` we intend to route to a given stream or circuit internally. Previously we called this a `RelayCell`, but that name was already somewhat inaccurate, and will become _very_ inaccurate with the arrival of prop340, which breaksthe 1:1 relationship between relay cells and relay messages. (If we didn't do this renaming now, we'd soon be making the relationship between `UnparsedRelayCell`and `RelayCell` many-to-many, which would be ridiculous and confusing.) The `RelayMsgOuter` name is a placeholder: We expect that we'll want to rename this type, and may also want to rename `RelayMsg`, and unify our vocabulary in other areas too. But such a renaming will have to wait for a larger discussion affecting the specifications, so that we can use the same vocabulary everywhere.
* NtorV3Extension set encoding/decoding: include n_extensionsJim Newsome2023-12-071-3/+3
| | | | | | | | | | An encoded set of extensions in the ntorv3 handshake includes a header with the number of extensions. This change adds that header. It also changes `write_many_onto` to take a slice instead of an iterator, since we need to know the number of extensions up-front. In principle we could take a clonable iterator instead and use Iterator::count, but it's probably not worth the extra complexity.
* Merge branch 'semver-breaking-upgrade-of-the-daleks' into 'main'Nick Mathewson2023-11-293-15/+14
|\ | | | | | | | | | | | | Convert to the latest versions of dalek-cryptography Closes #808 See merge request tpo/core/arti!1767
| * Remove RngCompatExt.Nick Mathewson2023-11-292-7/+6
| | | | | | | | | | | | | | | | | | | | This code was needed with the old version of dalek-cryptography, which wasn't compatible with up-to-date versions of the `rand` crate(s). But now that we've upgraded, we can drop this. (We could have left it around and deprecated it, but we are already making a breaking change to tor-llcrypto by upgrading dalek-cryptography.)
| * Convert to the latest versions of dalek-cryptographyNick Mathewson2023-11-293-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main changes that we have to adjust for are as follows: * In x25519-dalek: * `StaticSecret` is now behind a feature. * `StaticSecret::new` is deprecated in favor of `StaticSecret::random_from_rng`. * StaticSecret no longer does its own clamping. * In ed25519-dalek: * `SecretKey` has (in effect) been renamed to `SigningKey`. The name `SecretKey` is now an alias for `[u8; 32]`. * `SigningKey` is effectively a keypair, since it contains a public key as well. * `PublicKey` has been renamed to `VerifyingKey`. * The functions to extract a signing key and verifying key have been renamed as you might expect. * `ExpandedSecretKey` has been moved to `hasmat` and no longer implements `sign`. * `ExpanededSecretKey` now has as its elements a scalar and a hash prefix. * Various functions that took `&[u8]` now take `&[u8; N]`. * We no longer need a wrapper for older versions of rand. There is a single test in tor-keymgr that does not pass. I've marked it as ignore for now, in hopes that @gabi-250 can help me figure it out. This closes #808. There are several changes I want to make before we merge, however. They are marked with TODO DALEK.
* | debug log: Downgrade circuit lifecycle messages to traceIan Jackson2023-11-291-4/+4
| | | | | | | | | | | | This makes it possible to see the wood for the trees. This may be controversial, but I think it's an improvement.
* | Downgrade some messages to traceIan Jackson2023-11-292-2/+2
|/ | | | | These messages are very verbose and I doubt anyone will want them, usually, even when debugging.
* Fix 'target' in doc comment for create_firsthop_ntorJim Newsome2023-11-271-1/+1
|
* Test extend_ntor_v3Jim Newsome2023-11-271-10/+33
|
* Parameterize circuit-extension test by handshake typeJim Newsome2023-11-271-55/+68
|
* Add `ClientCirc::extend_ntor_v3`Jim Newsome2023-11-272-0/+78
|
* tor-proto::circuit::reactor: handle server auxiliary handshake dataJim Newsome2023-11-271-10/+81
|
* Circuit reactor: test ntor-v3 "create"Jim Newsome2023-11-271-43/+101
|
* Add NtorV3SecretKey::generate_for_test and NtorV3SecretKey::newJim Newsome2023-11-271-39/+36
|
* Add PendingClientCirc::create_firsthop_ntor_v3Jim Newsome2023-11-271-0/+43
|
* Add Reactor::create_firsthop_ntor_v3Jim Newsome2023-11-271-0/+50
|
* NtorV3PublicKey: make fields pub(crate), as for NtorPublicKeyJim Newsome2023-11-271-2/+2
|
* Use HandshakeType in Extend2 and CircuitExtender::beginJim Newsome2023-11-271-2/+2
|
* Merge remote-tracking branch 'public/hs_begin'Nick Mathewson2023-11-161-0/+1
|\
| * hsrproxy: Send back DONE reasons.Nick Mathewson2023-10-231-0/+1
| | | | | | | | | | This is in keeping with the behavior of C tor, and of torspec!179.
* | Send less information in onion service BEGIN messagesNick Mathewson2023-11-152-1/+39
| | | | | | | | | | | | | | | | | | While looking for differences, we found that C tor always omits the flags and the hostname from a BEGIN message sent on an onion service circuit. In torspec!179, we specified that behavior. This patch brings arti into conformance. Closes #1077.
* | tor-proto: make ClientHandShake and ServerHandshake generic over aux dataJim Newsome2023-11-156-164/+112
| |
* | Add NtorV3Server and implement ServerHandshake for itJim Newsome2023-11-151-29/+43
| |
* | ServerHandshake: extend to support ntorv3 extensionsJim Newsome2023-11-154-20/+130
| |
* | NtorV3Client: implement ClientHandshakeJim Newsome2023-11-151-7/+13
| |
* | ClientHandshake: extend to support ntorv3 extensionsJim Newsome2023-11-154-22/+66
| |
* | NtorV3Client: take a slice instead of a vec of extensionsJim Newsome2023-11-151-5/+3
| |
* | ntor_v3: replace `impl digest::XofReader` with `NtorV3XofReader`Jim Newsome2023-11-151-15/+20
| |
* | CircuitHandshake::Ntor::ed_identity clarify doc-commentJim Newsome2023-11-151-2/+2
| | | | | | | | | | Use consistent phrasing when describing the two key fields to make it clear they're referring to the same relay.
* | hs_ntor: fix comment typo INTROUDCE1Jim Newsome2023-11-151-1/+1
| |
* | circuit: On SendMsgAndInstallHandler, tolerate None handlerNick Mathewson2023-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Previously it was possible for `handler` to be None only when `msg` was also None, which would make SendMsgAndInstallHandler into a no-op. Now, if `msg` is present but `handler` is absent, we use the previously installed handler, which I think was our intention. Without this patch, `Conversation::send_message` simply won't work. Fixes #1085.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:16:41 +0000