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.
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.
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.
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.
These functions consume a checkable wrapper, and return a new
checkable wrapper with mapped contents but the same not-yet-checked
constraints.
As documented, They are "dangerous" because the provided function
gets access to the contents before they are checked; the caller has
to make sure that the provided function doesn't expose their
contents inappropriately.
There are some places where I note certificates which are not
currently validated, because there is no cryptographic point in
doing so. We should either document that this is okay, or validate
the certificates anyway.
This code might benefit from refactoring to make it prettier.
It turns out that C Tor doesn't add a newline at the end of the
middle layer of an onion service descriptor. I've made a spec MR
(torspec!109) to document this: here, it's time to work around the
issue.
Nick Mathewson
Dimitris Apostolou
eta