| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Use "throws" terminology to avoid having to clutter the description
with Err(). Many of these doc comments contain otiose text such as
"returns Ok(()) on success" but let's not deal with that now.
|
| | |
|
| |
|
|
|
|
|
|
| |
And rename its variants and update the docs to contemplate wider use,
as suggested in #1620.
As discussed here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2407#note_3075658
|
| |
|
|
|
| |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2407#note_3075638
|
| |
|
|
| |
No semver implications since this wasn't in the last release.
|
| |
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2407#note_3075486
|
| |
|
|
| |
This was a leftover from before I invented Error::MissingData.
|
| | |
|
| |
|
|
|
| |
Fix semantic conflict of the suggested edit with the rename later in
the branch.
|
| |
|
|
|
| |
Suggestion from here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2407#note_3075481
|
| |
|
|
|
|
|
|
|
| |
deprecated
Incomplete is a better name.
This lets us use Truncated for the old, deprecated, conflation of
"Incomplete" with what is now "MissingData".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce the new constructor and call it at the error generation
sites. But there is still not yet any functional change.
Change the type of Truncated's field to be Sensitive.
The original reason for not doing this no longer applies, since we
don't generally want to open-code construction of this variant.
Conveniently, changing the type means we get to find all the sites
where one *is* constructed and adjust them.
In reader.rs and tor-proto we can just call incomplete_error.
In tor-cell, there's a call site where we previously provided an
underestimate, and where the Reader isn't available. We adjust that
ad-hoc but this is fine because the error variant will
change. (relaycell is using a Reader from from_slice.)
|
| |
|
|
|
|
|
| |
Here we add the constructor, and document it, and change the call
sites.
No functional change yet.
|
| |
|
|
| |
Some tests in other crates test this, but none in tor-bytes!
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The codebase uses `r` sometimes and `b` at other times.
Making this consistent makes widespread changes easier, and is
clearer for humans.
I think `b` is better than `r` because `r` might be "return".
It is indeed used that way in a couple of places in reader.rs, even.
I haven't changed *everywhere*, just Readable impls (where `r` is
particularly likely to be "return value") and occurrences in
tor-bytes.
No functional change.
|
| | |
|
| |
|
|
| |
This will allow us to fix #1592, but it doesn't do so yet.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This removes one construction site of Error::Truncated. We are about
to make constructing one of those more fiddly.
|
| |
|
|
|
| |
Part of #872: Now that const generics are in, we have better ways to
express converting slices into array-references.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if somebody wrote this code, an attacker could easily
use it to cause an OOM panic:
```
let n = r.take_u64();
let items: Vec<Foo> = r.extract_n(n as usize)?;
```
The first line of defense here is not to write protocols like that:
we don't actually _have_ any 32-bit counters in our protocol
AFAICT.
The second line of defense is to pre-check `n` for reasonableness
before calling `extract_n`.
Here we add a third line of defense: whereas previously we would do
`Vec::with_capacity(n)` in `extract_n`, we now allocate an initial
capacity of `min(n, r.remaining())`. This ensures that the size of
the allocation can't exceed the remaining length of the message,
which (for our cell types at least) should prevent it from
overflowing or running OOM.
|
| | |
|
| | |
|
| |
|
|
|
| |
We'll use this to implement signature and MAC checking for
EstablishIntro cells.
|
| |
|
|
| |
See c489e1d9118edd842f80b76a636037524a45ee45
|
| |
|
|
| |
I disagree with almost all of these layout decisions...
|
| |
|
|
|
|
|
|
|
|
| |
This eliminates the possibility of writing the bug of failing to call
`should_be_exhausted`.
As per this discussion
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/572#note_2811464
Fixes #498
|
| | |
|
| | |
|
| |
|
|
| |
We'll want this in a moment.
|
| |
|
|
|
| |
I'm alright with allowing cognitive-complexity violations in the
tests.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that we have const generics, we can use them. We can also avoid
an extra clone in the implementation for [u8; N].
Nothing in our codebase requires that we use Reader or Writer on a
GenericArray holding anything other than u8, so I've switched back
to the more efficient implementation there.
I've added a fuzzer case for the new method, but apparently rustc nightly isn't working too
well with fuzzers for me; I'm going to try it tomorrow.
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|