summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell
Commit message (Collapse)AuthorAgeFilesLines
* cell: Make EstablishRendezvous contain a RendCookie.Nick Mathewson2023-05-231-5/+2
|
* cell: Make Introduce2::new testing-only.Nick Mathewson2023-05-171-1/+6
| | | | | | We never want to create one of these from its parts except when we are testing it; we only want to forward an Introduce1 message with a new command on it.
* cell: Record the text of an INTRODUCE2 headerNick Mathewson2023-05-171-9/+39
| | | | | We'll need to store this so that it can later on be used to complete the hs_ntor handshake.
* cell: extract introduce headers into a new type.Nick Mathewson2023-05-171-20/+42
| | | | | | | | We'll want this because our hs_ntor handshake requires access to an encoded version of the header independent from the actual encrypted message. part of #866.
* Change CircTarget::linkspecs() to return an encoded list.Nick Mathewson2023-05-101-3/+3
| | | | | | | | If we didn't do this, we would need to transfrom `EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not semantically right. What's more, every user of this API wants to consume encoded link specifiers, so encoding them early saves a little effort.
* Rename UnparsedLinkSpec => EncodedLinkSpecNick Mathewson2023-05-101-3/+3
|
* Move responsibility for linkspec sorting to CircTarget.Nick Mathewson2023-05-101-3/+1
| | | | | | This change is necessary so that we can build Extend2 messages that have their LinkSpecs appear in a verbatim order as provided in an INTRODUCE2 message or in a HS descriptor.
* Upgrade to bitflags 2.0Nick Mathewson2023-03-131-0/+1
| | | | | This version of bitflags now requires us to explicitly list the traits that we want to derive for our bit-flags structs.
* Serval rustdoc link fixes.Nick Mathewson2023-03-081-2/+2
|
* intro_payload: various doc fixes and TODOs from review.Nick Mathewson2023-03-081-4/+16
|
* tor-cell: Be a little more pedantic about INTRODUCE cell types.Nick Mathewson2023-03-081-3/+3
|
* tor-cell: Better describe the parts of intro payload.Nick Mathewson2023-03-081-3/+23
|
* tor-cell: Add code for the payload of an hs-ntor handshake.Nick Mathewson2023-03-062-0/+143
| | | | | | (This is the encrypted information inside the INTRODUCE2 cell; it's used by the client to tell the service where to find its rendezvous point.)
* Merge branch 'rename_rend_message' into 'main'Nick Mathewson2023-03-011-15/+18
|\ | | | | | | | | tor-cell: Rename Rendezvous*::message to handshake_info. See merge request tpo/core/arti!1045
| * tor-cell: Rename Rendezvous*::message to handshake_info.Nick Mathewson2023-03-011-15/+18
| | | | | | | | Follow-up from !1038
* | tor-cell: Use a match when checking auth_key_typeNick Mathewson2023-03-011-6/+8
| |
* | tor_cell: Use nested readers and writers for EstablishIntroNick Mathewson2023-03-011-18/+12
| |
* | tor-cell: tweak comments on EstablishIntro members.Nick Mathewson2023-03-011-2/+2
| |
* | Introduce a constant for the length of the output of hs_mac()Nick Mathewson2023-03-011-3/+3
| |
* | tor-cell: Rename EstablishIntro{Body => Details}Nick Mathewson2023-03-011-8/+8
| |
* | tor-cell: Make EstablishIntro do signaturesNick Mathewson2023-03-011-38/+229
|/ | | | | | | | | | | | | | | | The old code parsed and encoded a signature and a mac... but there was no way to actually set them properly. Now EstablishIntro is built around an EstablishIntroBody, and has the ability to check signatures and macs. Because there is no way to handle one of these messages if we can't check the signature, we no longer accept unrecognized `auth_key` types in this message. I've added a test to make sure that we can validate a message from the C tor implementation, and a test to make sure we can validate our own cells. I also had to modify the previous tests so that their keys were well-formed.
* Change several cfgs to refer to new feature names.Nick Mathewson2023-02-281-12/+12
|
* tor-cell: Support extensions in INTRODUCE{1,2}Nick Mathewson2023-02-281-10/+22
|
* tor-cell: Implement IntroduceAck and IntroEstablishedNick Mathewson2023-02-281-19/+85
| | | | | These are fairly simple, since the bulk of them is just an extension list with no supported extensions.
* tor-cell: Implement rendezvous1 and rendezvous2.Nick Mathewson2023-02-281-4/+38
|
* Rename onion-* cargo features to hs-* in tor-* cratesIan Jackson2023-02-281-12/+12
| | | | Fixes #756
* Rearrange cfg_attr in relaycell::msgNick Mathewson2023-02-211-2/+2
| | | | | docsrs wants to find its `cfg_attr(docsrs...)` line after the `cfg()` line.
* Merge branch 'hs-cells-1' into 'main'Nick Mathewson2023-02-165-462/+669
|\ | | | | | | | | Start refactoring hs cell implementations See merge request tpo/core/arti!1020
| * Mark a quoted block as text, so doctest ignores it.Nick Mathewson2023-02-161-1/+1
| |
| * Add a TODO about combining several macros and patternsNick Mathewson2023-02-161-0/+4
| |
| * Make a comment more accurateIan Jackson2023-02-161-1/+3
| |
| * tor-cell: Use a more generic mechanism for managing extensionsNick Mathewson2023-02-153-56/+249
| | | | | | | | | | | | | | | | | | | | Several HS message types have an extension list type. They all use the same framing for extensions, but each of them has separate extension types and separate extension namespaces. This commit simplifies establish_intro a little, and adds support for maintaining unrecognized extension types--at the expense of some new internal code.
| * tor-cell: Extract establish-intro into its own module.Nick Mathewson2023-02-153-214/+222
| | | | | | | | | | | | | | Some of the HS message types have a lot of dependent types, like extensions and options for those extensions, and so on. Except when those extensions are portable across cell types, it makes sense to put them in their own modules.
| * tor-cell: rename onion_service module to hsNick Mathewson2023-02-152-1/+1
| |
* | tor-cell: add a TODO comment about simplifying Body away.Nick Mathewson2023-02-151-0/+4
| |
* | tor-cell: Implement {Relay,Chan}Msg for every body typeNick Mathewson2023-02-151-0/+46
| | | | | | | | | | This will make it ergonomic to decode a single body type without having to declare a variant that accepts only a single message.
* | tor-cell: Note an opportunity for future optimizationNick Mathewson2023-02-151-0/+5
|/
* Change tor_bytes::Error::BadMessage to a Cow.Nick Mathewson2023-02-094-17/+25
| | | | | | | | | | Actually, to avoid making a breaking change, I'm deprecating BadMessage and creating a new InvalidMessage variant that takes a Cow. This way I don't need to track every crate that re-exposes tor_bytes::Error and call this a breaking change in those. Making this change will allow tor_bytes errors to be much more helpful.
* tor-cell: Have restrict_msg add conversion functions.Nick Mathewson2023-02-093-90/+1
| | | | | | | | | | | | | | | | Every FooMsg type now implements Into<AnyFooMsg>, and TryFrom<FooMsg>. Additionally, it now implements From<X> for every distinct type that it supports. This last part lets us discard a bunch of code. Unfortunately, I needed some downright hackish trickery in order to get these macros to avoid generating `From<AnyFooMsg> for AnyFooMsg` and conflicting with the blanket implementation. The trickery to deal with RelayEarly and Relay being the same type was not necessarily worth it; I will be separating them and removing said trickery in the next commit.
* tor-cell: documentation cleanups related to restricted_msgNick Mathewson2023-02-071-0/+2
|
* tor-cell: correct handling of optional msg types.Nick Mathewson2023-02-071-12/+12
| | | | | | We need to make sure any `#[cfg(feature=...)]` attributes are applied not only to our variant declarations, but also to the branches in the match statements that deal with them.
* tor-cell: Rename RelayMsg and RelayCell-related types.Nick Mathewson2023-02-073-50/+50
| | | | Thanks to rust-analyzer for making this simple.
* tor-cell: Remove RelayMsg methods that are duplicated in RelayMsgClass.Nick Mathewson2023-02-071-15/+0
|
* tor-cell: Use macro to define RelayMsg type too.Nick Mathewson2023-02-072-185/+103
|
* tor-cell: Change all variants of RelayMsg to have a body.Nick Mathewson2023-02-071-12/+49
| | | | | Previously, there were some unit variants, but that makes things quite awkward for #525.
* tor-cell: Make Body and MsgClass traits more uniform.Nick Mathewson2023-02-073-30/+30
| | | | | | | | Doing this will make it much easier to implement a macro that generates restricted instances of the Msg types (for #525). The Body change is a breaking change. I don't think anybody else implements Body, but in theory they could.
* tor-cell: Generic "Restricted{Relay,Chan}Cell" types.Nick Mathewson2023-02-071-7/+20
| | | | | | | These are generalizations of RelayCell and ChanCell respectively, that allow using an arbitrary message type in place of the fully general RelayMsg and ChanMsg types. Doing this is a prerequisite for usefully implementing arti#525.
* Fix typosDimitris Apostolou2023-01-071-4/+4
|
* Sketch a solution for arti#525Nick Mathewson2023-01-061-0/+34
|
* Sketch out new required APIs in tor-cellNick Mathewson2023-01-062-8/+124
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 00:53:11 +0000