| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/ / / / / / |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-netdoc: Rename variants in VerifyGeneralTrustedAuthorities
See merge request tpo/core/arti!4099
|
| | | | | | | | |
|
| | | |/ / / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In a wip branch I added a variant, and clippy complained. In this
case, I agree with clippy.
warning: all variants have the same postfix: `Authorities`
--> crates/tor-netdoc/src/doc/netstatus.rs:2335:1
|
2335 | / pub(crate) enum VerifyGeneralTrustedAuthorities<'r> {
2336 | | /// Trust these authorities.
2337 | | TrustTheseAuthorities {
2338 | | /// The HKP_auth_id_rsa
... |
2357 | | },
2358 | | }
| |_^
|
= help: remove the postfixes and use full paths to the variants instead of glob imports
= help: for further information visit https://rust-lang.github.io/rust-clippy/beta/index.html#enum_variant_names
note: the lint level is defined here
--> crates/tor-netdoc/src/lib.rs:9:9
|
9 | #![warn(clippy::all)]
| ^^^^^^^^^^^
= note: `#[warn(clippy::enum_variant_names)]` implied by `#[warn(clippy::all)]`
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Always use destroy reason NONE in circuit handshake code
Closes #2466
See merge request tpo/core/arti!4088
|
| | | | | | | |
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The spec was recently updated in [1],
so we should make this clearer in our code comments.
[1]: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/490
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-netdoc: overhaul consensus verification, in preparation for parse2 ns verification
See merge request tpo/core/arti!4065
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4065#note_3423331
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This avoids passing the threshold around as a bare usize, separated
out from the list of trusted authorities.
Roughly as discussed in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4065#note_3423775
But, VGTA::HazardouslyAssumeAllAuthCertsAreRealAuthorities contains
n_authorities, not the thtreshold. That's what its user has, and that
allows us to centralise the threshold calculation somewhat.
The situation with votes in poc is a bit odd now: we pass one cert and
then there's one authority so the threshold of 1 is calculated rather
than literal. That's OK, but also we perhaps aren't going to use
verify_general for votes in the production.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
No functional change with the existing caller.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Introduce ConsensusVerifiabilityError.
No functional change with the existing callere, which discards the
error value.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Now the caller can use .map_err rather than if .ok().
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Move the body of check_signature into verify_general.
check_signature was the only thing that returned SigCheckResult.
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
And split check_signature into signature_to_verify which obtains a
ConsensusSignatureToVerify, and then a call to .verify().
The return values are still a bit janky.
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In an attempt to check that the new verification code makes sense, we
compare it with the freshly rewritten one in poc.
To review this, compare the code being deleted with the body of
verify_general (doc/netstatus.rs, line 2164 et seq).
You'll also want to refer to the body of find_cert and
check_signature (lines 2068-2086).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Like verify_general does.
(This wasn't a bug before, because we could the length of ok, so all
that would happen is we'd do some extra work.)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Obtain the hash first, like verify_general does.
No significant functional change, and this is poc code anyway.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This makes the code more like that in verify_general.
No functional change, and this is poc code anyway.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously this was arguably needed for clarity. With the new hash
finding arrangements, much less so.
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use an exhaustive pattern. This allows us to spot any fields which
we omit to look at, which would be an indication of a possible bug.
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
No functional change with the current caller.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This does not fix the bug with the old parser. The old parser always
uses the `sha1` field in `hashes` even when `sha1_unnamed` would be
right. But it also always sets `sha1`.
Or to put it another way, because the old parser parses an unspecified
algorithm as if it were explicitly `sha1`, it then both sets the
digest_algo to DigestAlgoInSignature(Some(...)), and writes the hash
to the `sha1` field.
So this does not have an overall functional change with the old
parser, and nothing else calls this.
I'm fixing this here, now, so that the new parser doesn't inherit the
bug. The new parser will set `digest_algo` correctly, and correctly
write the hash to `sha1` or `sha1_unnamed`.
What a terrible protocol this is.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
No functional change.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is going to be the entrypoint for sharing verification code with
parse2. For now it must be pub(crate) since we're going to call it
from poc.
No functional change.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add NtorOnionKeyCrossCert
See merge request tpo/core/arti!4023
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This commit adds a unit test for NtorOnionKeyCrossCert that tests
whether it can be successfully decoded and verified if enough fields are
given.
The test itself is performed on keys with a negative as well as keys
with a positive sign as the argument.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit adds the NtorOnionKeyCrossCert data type; a data type
implementing ItemValueParseable, intended for use within RouterDesc and
parse2.
This type wraps around the previously added Ed25519NtorCrossCert type in
a fashion that honors the `bit` argument.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
tor-netdoc: sort out recommended software versions items
See merge request tpo/core/arti!4059
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4059#note_3424494
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
An existing real consensus says something like this:
client-versions 0.4.8.19,0.4.8.20,0.4.8.21,0.4.8.22,0.4.8.23,0.4.8.24,0.4.8.25,0.4.9.4-rc,0.4.9.5,0.4.9.6,0.4.9.7,0.4.9.8
so it's not using the additional arguments, and the spec says those
should be ignored.
See also torspec!500.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is a single comma-separated argument, with absence of the item
being the same as absence of the arguemnt.
The previous code had `Vec<String>` which in parse2 would mean zero or
more occurrences of the item, with one argument each.
The old parser would split the whole RHS of the arguments. It still
does right now - we'll fix that in a moment.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will make the next change here slightly less confusing.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Again, this is going to get more complicated, so let's make a closure.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is going to get more complicated, so let's make a closure for it.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This would let us use `.parse_arg::<String>()` in old parsing code.
I wanted this for recommended versions, and then didn't use it, but it
seems useful anyway.
|
| |/ / / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
tor-netdoc: Replace ad-hoc pseudo-diff with unidiff from imra
See merge request tpo/core/arti!4096
|
| | | | | | | |
|
| | | | | | | |
|
