| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This version of bitflags now requires us to explicitly list the
traits that we want to derive for our bit-flags structs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(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 Rendezvous*::message to handshake_info.
See merge request tpo/core/arti!1045
|
| | |
| |
| |
| | |
Follow-up from !1038
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
These are fairly simple, since the bulk of them is just an extension
list with no supported extensions.
|
| | |
|
| |
|
|
| |
Fixes #756
|
| |
|
|
|
| |
docsrs wants to find its `cfg_attr(docsrs...)` line after the
`cfg()` line.
|
| |\
| |
| |
| |
| | |
Start refactoring hs cell implementations
See merge request tpo/core/arti!1020
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Also, add some comments about how it is likely to change.
|
| | | |
|
| | |
| |
| |
| |
| | |
This will make it ergonomic to decode a single body type without
having to declare a variant that accepts only a single message.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
It's now redundant, since `restricted_msg!` defines From and Into
for us.
|
| |
|
|
| |
This allows us to remove a shenanigan from `restricted_msg!{}`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.)
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Thanks to rust-analyzer for making this simple.
|
| | |
|
| | |
|
| | |
|
| | |
|