summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Merge branch 'assert_maxlen' into 'main'Nick Mathewson2022-10-271-1/+2
|\ | | | | | | | | tor-cell: Assert data length in Data cells See merge request tpo/core/arti!800
| * tor-cell: Assert data length in Data cellsEmil Engler2022-10-241-1/+2
| | | | | | | | | | | | This commit adds a `debug_assert!` macro into the `new_unchecked()` function of the Data cell. Beside this, it also fixes a misleading comment regarding that limit.
* | Merge branch 'safe_u16_conversion' into 'main'Nick Mathewson2022-10-251-1/+1
|\ \ | | | | | | | | | | | | tor-cell: Consistent and secure conversion to u16 See merge request tpo/core/arti!803
| * | tor-cell: Consistent and secure conversion to u16Emil Engler2022-10-241-1/+1
| |/ | | | | | | | | | | | | This commit improves the overflow protection of one call to Vec::write_u16(), by replacing the cast conversion from self.sig.len() with a call to u16::try_from(), like it is already done in the rest of the accompanying function.
* | Merge branch 'fix_typos' into 'main'eta2022-10-251-2/+2
|\ \ | | | | | | | | | | | | tor-cell: Fix typos in msg.rs See merge request tpo/core/arti!802
| * | tor-cell: Fix typos in msg.rsEmil Engler2022-10-241-2/+2
| |/
* / tor-cell: Add comment explaing Data::MAXLENEmil Engler2022-10-241-0/+1
|/ | | | | This commit adds a comment explaining composition of the magic number "11" found in the assignment of the Data::MAXLEN constant.
* Merge branch 'cell-introduce2' into 'main'Ian Jackson2022-09-262-15/+64
|\ | | | | | | | | Implement Introduce2 tor cell See merge request tpo/core/arti!736
| * Implement Introduce2 tor cellYuan Lyu2022-09-212-15/+64
| | | | | | | | | | Reuse the same Introduce inner body implementation of Introduce1.
* | Intoduce1: Use a constant-time check for all-zero RsaIdentityNick Mathewson2022-09-201-2/+3
|/ | | | | | | | | | | | As a matter of good crypto practice, we shouldn't use short-circuiting checks to compare keys or key-like objects, since the amount of time taken by those checks can leak information about their inputs. I don't think it's actually _necessary_ to use a constant-time operation in this case, but let's establish the precedent. This is a follow-up to !724.
* Implement onion service Introduce1Yuan Lyu2022-09-082-1/+74
|
* Clean up EstablishIntro cellYuan Lyu2022-08-251-12/+162
|
* Clarify `REASON_DONE`Emptycup2022-08-161-1/+1
|
* Implement establish rendezvous cellYuan Lyu2022-08-052-1/+42
|
* Several typo fixes from `typos`.Nick Mathewson2022-07-271-1/+1
|
* Fix compilation of EstablishInto encoding.Nick Mathewson2022-07-221-2/+3
| | | | It was based on the old `Writeable` API.
* Merge branch 'hs-cells' into 'main'eta2022-07-222-1/+86
|\ | | | | | | | | Implement ESTABLISH_INTRO relay cell See merge request tpo/core/arti!626
| * Implement ESTABLISH_INTRO relay cellYuan Lyu2022-07-182-1/+86
| |
* | Merge branch 'fallible_writers_v2' into 'main'Nick Mathewson2022-07-193-53/+90
|\ \ | | | | | | | | | | | | | | | | | | Revise tor_bytes::Writer::write to return a Result. Closes #513 See merge request tpo/core/arti!623
| * | tor-cell: Stop using write_infallibleNick Mathewson2022-07-112-23/+38
| | | | | | | | | | | | Also, stop using "expect" and "assert!" to check for errors.
| * | tor-cell: Make encoding method signatures fallible.Nick Mathewson2022-07-112-21/+37
| | |
| * | Convert each write_onto_infallible implementation into write_onto.Nick Mathewson2022-07-113-10/+16
| | |
| * | Rename "write" methods on tor-bytes to "write_infallible".Nick Mathewson2022-07-113-21/+21
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This comprises four renames: ``` write_onto -> write_onto_infallible write_into -> write_into_infallible write -> write_infallible writer_and_consume -> write_and_consume_infallible. ``` The rest of this branch will be concerned with replacing these `_infallible` methods with ones that return a `Result`. This is part of #513.
* / tor-cell: Derive Eq for NtorV3ExtensionIan Jackson2022-07-181-1/+1
|/ | | | Apropos clippy complaint.
* Implement a higher-level API for the ntor v3 handshakeeta2022-07-081-0/+115
| | | | | | | | | | | | | | | | | | | This implements a higher-level API for the ntor v3 handshake, in line with that exposed by the ntor handshake. It does not, however, use the existing `ClientHandshake` trait, due to fundamental differences in the handshakes (namely, that the v3 handshake can include some additional extra extension data). Currently, the higher-level API assumes circuit extension, and copies the (undocumented!) magic verification string from c-tor that indicates this usage. A rudimentary set of functions for serializing and deserializing extensions to be sent with the handshake is also included, implementing the protocol in proposal 332 § A.2. Currently, it only implements the congestion control extensions specified in proposal 324 § 10.3. part of arti#88
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 01:13:49 +0000