summaryrefslogtreecommitdiff
path: root/crates/tor-cell/tests
Commit message (Collapse)AuthorAgeFilesLines
* tor_bytes: Rename new_truncated_for_test to new_incomplete_for_testIan Jackson2024-09-121-2/+2
| | | | No semver implications since this wasn't in the last release.
* tor-bytes: Only report Truncated for errors at the outer levelIan Jackson2024-09-111-2/+2
| | | | | | | | | | | This is item 1 from https://gitlab.torproject.org/tpo/core/arti/-/issues/1614#note_3074562 and the alternative to item 2 presented in the 2nd half of https://gitlab.torproject.org/tpo/core/arti/-/issues/1614#note_3074648 (Item 3 was done earlier, but now we change the behaviour.) Fixes #1614.
* tor-bytes: Add a Reader constructor for use in testsIan Jackson2024-09-111-4/+4
| | | | | | | | | | | | We could call from_possibly_incomplete_slice in these, but that's confusing and distracting. Here we add this constructor, and document it (in terms of the constructor to come), and change the call sites. No functional change. Doing this now will prevent unwanted changes to test behaviours when we change the behaviour of Readers made by Reader::from_slice.
* Introduce and use tor_bytes::Error::new_truncated_for_test (fmt)Ian Jackson2024-09-101-1/+5
|
* Introduce and use tor_bytes::Error::new_truncated_for_testIan Jackson2024-09-101-4/+4
| | | | | | | | This is going to want to do something more complicated (as described in the docs). In this commit we change all the tests that are expecting Truncated errors. That reduces noise in the next commit.
* relay-cell: Update relay cell decoding API for prop340Jim Newsome2024-03-121-5/+7
| | | | | | | | | | | Prop 340: https://spec.torproject.org/proposals/340-packed-and-fragmented.html This updates the decoding API to support multiple versions of the relay cell encoding, including the new encoding proposed in prop340 that supports relay message packing and fragmentation. This commit doesn't actually add support for that new encoding yet.
* Rename UnparsedRelayCell -> UnparsedRelayMsgJim Newsome2024-03-121-2/+2
| | | | | For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-131-1/+1
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* clippy: consequential rustfmtIan Jackson2024-01-021-2/+1
|
* clippy: Use infallible callsIan Jackson2024-01-021-2/+1
| | | | Resolves clippy complaints about needless fallible conversions.
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove RngCompatExt.Nick Mathewson2023-11-291-2/+2
| | | | | | | | | | 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-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use HandshakeType in Extend2 and CircuitExtender::beginJim Newsome2023-11-271-2/+3
|
* Add a caret_int HandshakeType for HTYPE constantsJim Newsome2023-10-261-3/+8
|
* Change `CircId` to never be zeroJim Newsome2023-10-251-9/+9
| | | | | | | | | | This changes the internal representation to be `NonZeroU32` instead of just `u32`. Various places where a circuit ID is optional now use `Option<CircId>`. Fixes a bug in `CircIdRange::sample` that would previously return a circuit ID of 0, when the rng returned 0x8000_0000 for a low range.
* Convert StreamId to NonZeroU16Jim Newsome2023-10-251-11/+10
|
* cell: Make EstablishRendezvous contain a RendCookie.Nick Mathewson2023-05-231-1/+1
|
* Change CircTarget::linkspecs() to return an encoded list.Nick Mathewson2023-05-101-1/+5
| | | | | | | | 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.
* linkspec: Make LinkSpecType public.Nick Mathewson2023-05-101-4/+7
| | | | | This lets us check the type of an `EncodedLinkSpec` as well, and lets us remove an interface that took a raw u8.
* Rename UnparsedLinkSpec => EncodedLinkSpecNick Mathewson2023-05-101-4/+4
|
* tor-cell: Add code for the payload of an hs-ntor handshake.Nick Mathewson2023-03-061-0/+48
| | | | | | (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.)
* tor-cell: Rename EstablishIntro{Body => Details}Nick Mathewson2023-03-011-4/+4
|
* tor-cell: Make EstablishIntro do signaturesNick Mathewson2023-03-011-22/+72
| | | | | | | | | | | | | | | | 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-4/+4
|
* Mark new tests as onion-service-onlyNick Mathewson2023-02-281-0/+3
|
* tor-cell: Support extensions in INTRODUCE{1,2}Nick Mathewson2023-02-281-12/+4
|
* tor-cell: Implement IntroduceAck and IntroEstablishedNick Mathewson2023-02-281-0/+19
| | | | | 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-0/+22
|
* Rename onion-* cargo features to hs-* in tor-* cratesIan Jackson2023-02-281-4/+4
| | | | Fixes #756
* Merge branch 'hs-cells-1' into 'main'Nick Mathewson2023-02-161-26/+18
|\ | | | | | | | | Start refactoring hs cell implementations See merge request tpo/core/arti!1020
| * tor-cell: Use a more generic mechanism for managing extensionsNick Mathewson2023-02-151-23/+15
| | | | | | | | | | | | | | | | | | | | 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-151-1/+1
| | | | | | | | | | | | | | 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-151-4/+4
| |
* | tor-cell: Add a new UnparsedRelayCellNick Mathewson2023-02-151-2/+14
| | | | | | | | | | | | We'll use this to router relay messages on a circuit to the appropriate stream, and hand them to that stream, without parsing the message until the stream has been determined.
* | tor-cell: Refactor relay cells to copy much lessNick Mathewson2023-02-151-2/+2
|/ | | | | | | | | | | | | We now manipulate raw relay cell bodies as (an alias for) `Box<[u8;509]>` rather than as (an alias for) `[u8;509]`. This enables us to do much less copying. It will become more important soon, as we defer parsing relay cell bodies even longer. Related to #7. We also use SliceWriter to avoid allocating a Vec<> for every relay message we want to encode, and instead encode directly into the cell.
* Change tor_bytes::Error::BadMessage to a Cow.Nick Mathewson2023-02-093-12/+17
| | | | | | | | | | 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.
* cell: Parameterize ChannelCodec::decode and encode.Nick Mathewson2023-02-091-5/+6
| | | | | | | This change lets us use ChannelCodec to encode and decode any restricted channel message type we want. (Later on, we'll turn the related Codec class in tor-proto into a more type-restricted version of this.)
* tor-cell: Rename RelayMsg and RelayCell-related types.Nick Mathewson2023-02-072-20/+20
| | | | Thanks to rust-analyzer for making this simple.
* tor-cell: Rename ChanMsg and ChanCell-related types.Nick Mathewson2023-02-072-14/+14
|
* tor-cell: Remove RelayMsg methods that are duplicated in RelayMsgClass.Nick Mathewson2023-02-072-2/+2
|
* tor-cell: Remove ChanMsg methods that are duplicated in ChanMsgClass.Nick Mathewson2023-02-072-10/+6
|
* tor-cell: Use macro to generate ChanMsg too.Nick Mathewson2023-02-071-2/+2
|
* tor-cell: Change all variants of RelayMsg to have a body.Nick Mathewson2023-02-071-3/+3
| | | | | Previously, there were some unit variants, but that makes things quite awkward for #525.
* Disable clippy::unlinlined-format-argsNick Mathewson2023-01-274-0/+6
| | | | | | | | This warning kind of snuck up on us! (See #748) For now, let's disable it. (I've cleaned it up in a couple of examples, since those are meant to be more idiomatic and user-facing.) Closes #748.
* msg::{CreateFast/CreatedFast}: Rename accessor to (into_)body()Neel Chauhan2022-12-181-2/+2
|
* tor-cell: Rename for_client and for_relayEmil Engler2022-10-211-5/+5
| | | | | | | This commit renames the for_client and for_relay functions to from_client and from_relay respectively, in order to indicate their origin, as the term "for" is more likely to indicate a destination, which is not true in that situation.
* Fix various typos (using typos tool and hand-inspection)Nick Mathewson2022-10-181-2/+2
|
* Implement Introduce2 tor cellYuan Lyu2022-09-211-1/+3
| | | | | Reuse the same Introduce inner body implementation of Introduce1.
* Implement onion service Introduce1Yuan Lyu2022-09-081-5/+56
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:18:01 +0000