aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-cell/tests
Commit message (Collapse)AuthorAgeFilesLines
* Upgrade rand crates to 0.10.Wesley Aptekar-Cassels2026-05-122-9/+13
| | | | | | | | | | | When the circ-padding feature is enabled, we use maybenot, which does not yet support rand 0.10. In the meantime, enabling this feature pulls in rand 0.9. This is not ideal, but should be okay as a temporary situation. This also replaces the use of ReseedingRng (which was removed in 0.10) with the reseeding_rng crate. This is somewhat less performant, but it should be okay.
* proto: Remove the AUTHORIZE as a parsable cellDavid Goulet2025-08-211-15/+0
| | | | | | | | | | | | | The AUTHORIZE cell command is simply reserved but not defined. The tor specification, at this point in time, is allowing such cell before the handshake starts but it is very unclear on what ordering is allowed nor how many can are allowed. C-tor silents drop them like VPADDING and so clearly unused. Instead of dealing with it, simply remove its support but keeping its reserved number. Signed-off-by: David Goulet <[email protected]>
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-074-14/+19
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* tor-cell: change `UnparsedRelayMsg::data_len`Steven Engler2025-07-151-3/+19
| | | | | | | | | It now performs some validation and can return a `Result`. We perform validation here since different cell formats may have different maximum data lengths in the future, and `UnparsedRelayMsg` doesn't expose the cell format so it's difficult to perform this validation at a higher layer.
* tor-cell: add some testing for `UnparsedRelayMsg`Steven Engler2025-04-301-4/+27
|
* cell, proto: Use correct Data sizes for v1 relay cellsNick Mathewson2025-04-161-1/+2
| | | | | | | | | | | | Since v1 cells have a longer tag, they can fit less data into a single cell. Ah well, that's the cost of improved security. The code in data.rs is a little wonky, in that it currently requires its buffer to be exactly the maximum size for a data cell. We have a TODO about fixing that in the future, but for now I've moved it to use a boxed slice rather than a boxed array. Part of #1944.
* cell: Implement parsing and encoding for V1 relay cellsNick Mathewson2025-04-161-7/+77
| | | | This is the main part of #1944, and will be needed for CGO.
* Add a RelayCellFormat argument to encode().Nick Mathewson2025-04-161-2/+3
| | | | | | | | | This will let us actually _send_ messages in the right format. This approach is not ideal for packed/fragmented messages; they will need a separate RelayCellEncoder. part of #1944.
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-5/+1
| | | | - `try_fill_bytes()` is no longer a member of RngCore.
* tor-cell: Support encoding proofs-of-work in intro_payloadWesley Aptekar-Cassels2024-10-091-1/+1
| | | | | | | | | Like parameters, PoW solutions are versioned to account for multiple algorithms over time. A single solution of a specific version may accompany an INTRO1/2 as part of the encrypted extensions section. Its encoding may depend on the version. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* 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
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 19:11:18 +0000