| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2407#note_3075485
|
| |
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2407#note_3075483
|
| |
|
|
| |
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.
|
| |
|
|
|
| |
Tidy up an error message. Now this can be on one line with variable
name interpolation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
I just perpetrated a bug by adding a variant to this which ended up
not PartialEq to itself. This open-coded match is a footgun.
No functional change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2390#note_3072975
|
| | |
|
| |
|
|
| |
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 refers to the `deficit` field in Error::Truncated, which is going
to appear in a later commit. It seems kinder to my reviewer to add
this doc now early in the branch.
|
| |
|
|
|
| |
This removes one construction site of Error::Truncated. We are about
to make constructing one of those more fiddly.
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| |
|
|
|
|
|
| |
Use a saturating add while determining the new length. If it really ends
up being usize::MAX, the resize will most likely panic. This is at
least a more reliable end of processing than going on with a much
smaller vector than expected.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Instead of tying ourselves to a particular version of the
generic-array crate, we now always use the version re-exported by
our RustCrypto crates. This lets us avoid the possibility of
version mismatch.
(Originally I had planned to upgrade to generic-array 1.0, but then
I found that we were not actually using it.)
|
| | |
|
| |
|
|
|
|
| |
This commit deprecates the `EncodeError::always_bug` function with a
`From<EncodeError> for Bug` trait, which is a more semantically correct
way to perform this action.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|