| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
| |
This seems to depend on cfgs. As I say in #1060, I don't think
precise cfg decoration of imports is sensible.
Also, it shouldn't be my job to fix whatever this is...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I don't see any further changes being needed for these types, and it
simplifies a lot of future code in tor-proto that uses these types.
|
| | |
|
| |
|
|
|
|
| |
Clippy nightly detects this problem, though earlier clippy verisons
haven't. The common element here is applying unwrap() to the result
from a write!().
|
| |
|
|
|
| |
This doesn't make much change yet, but does save us an allocation
when handling SENDMEs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a more efficient representation for the tag on an
authenticated SENDME message: it comes in at 21 bytes.
Previously, we used Vec<u8>, which has 24 bytes of overhead
(on a 64 bit system), plus malloc overhead, plus 20 bytes of
allocated tag.
We had a similar type to this as
`tor_proto::congestion::sendme::CircTag`,
but it could only accomodate 20-byte values.
I don't expect that we will have enough of these simultaneously that
the memory savings will matter, but the allocation savings could be
significant.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
(Also note a couple of other CGO-related issues)
|
| | |
|
| |
|
|
|
|
|
| |
This adds support for encoding and decoding `RELAY_CONFLUX_LINK`,
`RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells.
Closes #1852
|
| | |
|
| |
|
|
|
|
|
| |
We never actually constructed these before, but now we enforce it at
the API level.
Part of #1269.
|
| |
|
|
|
|
|
|
|
|
|
| |
If we don't reject these, they are a way to inject an undetected
traffic signal. (This is LOW severity, since we only accept DATA
when a stream is open, since DATA messages are rate-limited,
and since using length==1 is nearly as effective.)
Closes #1269.
This is TROVE-2024-001.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rust 1.66, std's default works properly for enums, provided that
the default variant is a unit.
Review all uses of `#[educe(default)]` on enums and replace them with
std where possible, which is most of them.
In 1.66 and later, std's `#[derive(Default)]` doesn't infer any
generic bounds on the derived impl, where it's an enum - since the
unit variant can always be constructed. So this change doesn't add
any generic bounds and is not API-visible.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #887.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This change is necessary so that we can build Extend2 messages
that have their LinkSpecs appear in a verbatim order as provided
in an INTRODUCE2 message or in a HS descriptor.
|
| |
|
|
|
| |
This version of bitflags now requires us to explicitly list the
traits that we want to derive for our bit-flags structs.
|
| | |
|
| |
|
|
| |
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
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This will make it ergonomic to decode a single body type without
having to declare a variant that accepts only a single message.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
Previously, there were some unit variants, but that makes things
quite awkward for #525.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |\
| |
| |
| |
| | |
tor-cell: Assert data length in Data cells
See merge request tpo/core/arti!800
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-cell: Fix typos in msg.rs
See merge request tpo/core/arti!802
|