mirrors/arti.git/crates/tor-proto/src/channel/handshake.rs, branch arti-v1.4.6mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.62025-06-12T18:02:30Ztor-proto: Log channel, circuit, stream identifiers as structured fields.2025-06-12T18:02:30ZGabriela Moldovangabi@torproject.org2025-06-12T15:16:21Zurn:sha1:a50fe9c8471bfe026ff5a0ce39355258fc335fe0
This changes the `tor-proto` logs to not be prefixed with a
channel/circuit/stream ID, but rather to have these IDs attached to the
log as structured fields.
This change is in preparation for the switch to using `TunnelId`s in the
tunnel reactor instead of circuit `UniqId`s. The reason for the change
to use structured fields is because future logs will likely need to log
the `UniqId`s of the circuits in a tunnel, which will need to either be
formatted somehow in the logs, or logged as a structured field (the
latter seems like the better option, hence this preparatory change).
IMO we should favor structured fields over formatted strings in the
logs in general, but that is a bigger project, so I am only doing a
spot fix for now.
tor-proto: remove `use asynchronous_codec as futures_codec`2025-02-06T16:43:27ZNeel Chauhanneel@neelc.org2025-02-06T16:43:27Zurn:sha1:4c45faf700ae3043cf0961407ccdb686de847ac8
Closes #1690.
tor-proto: Pass a StreamOps handle to the channel reactor.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T11:15:47Zurn:sha1:7bf3db2d40d4548380cd7dbd4331ac018303528ctor-rtcompat: Big invasive change adding StreamOps bound everywhere.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T19:08:57Zurn:sha1:f04709c16d0ebf039779c404cf0c907f13965852
This is unfortunately necessary, because after the channel handshake, we
need to give the channel reactor a `StreamOps` handle to the underlying
stream.
tor-proto: Plumb the ChannelAccount through to queue creation site2024-10-03T14:10:47ZIan Jacksonijackson@chiark.greenend.org.uk2024-10-02T16:24:59Zurn:sha1:939d291ed3792a5fd1392f4e2816de254ac1bc12
This gets it as far as the outbound circuit->channel mpsc queue creation.
Also, we provide an accessor for it.
tor-proto: Plumb the ChannelAccount through to queue creation site (pre-fmt)2024-10-03T14:10:35ZIan Jacksonijackson@chiark.greenend.org.uk2024-10-02T15:32:47Zurn:sha1:17f55b3302cb254506f0ce2a3421211b55eb5bc4tor-proto: channel: Make construction fallible2024-10-03T14:10:35ZIan Jacksonijackson@chiark.greenend.org.uk2024-09-23T10:19:32Zurn:sha1:1861de6a00edd99c4354fc3b2eaaf88fec2d4fe6
Making a channel is going to involve making a memquota Participant,
which can fail.
tor-proto: Add a CoarseTimeProvider bound to all the SleepProviders (fmt)2024-10-01T18:05:25ZIan Jacksonijackson@chiark.greenend.org.uk2024-10-01T17:43:59Zurn:sha1:88d6f90b13fd8d0ddb538f833ff9531f8d308047tor-proto: Add a CoarseTimeProvider bound to all the SleepProviders2024-10-01T18:05:25ZIan Jacksonijackson@chiark.greenend.org.uk2024-09-23T10:08:41Zurn:sha1:88554acf6ecfaeffa459e88857aefd2e6d4cd99f
The memquota arranagements are going to use this.
We *don't* apply this to Channel (or to other types that aren't
already generic over SleepProvider).
UnverifiedChannel: Clarify check's peer_cert2024-07-11T18:35:18ZClara Englercve@cve.cx2024-07-11T18:35:18Zurn:sha1:0bafabfb8c6e326433386fe543948595f7ecbefd
This commit clarifies the documentation of the `peer_cert` parameter in
the `UnverifiedChannel::check` function, in order to reflect that it
represents the certificate presented during the ServerHello in the TLS
handshake and not in the in-protocol CERTS cell.