| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
tor-proto: remove `use asynchronous_codec as futures_codec` in `/channel/handler.rs`
Closes #1690
See merge request tpo/core/arti!4026
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
`/channel/handler.rs`
Closes #1690.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Introduce family-cert for RouterDesc
See merge request tpo/core/arti!4007
|
| | | | | |
| | | | |
| | | | |
| | | | | |
No functional change.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Removes a comment about the virtual/real distinguishment in RouterDesc
as there are no virtual items left anymore.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This item is no longer required because we can extract it from
family_cert.
Unfortunately it requires a breaking change to the getter.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We will need it in the next commit.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit adds the family_cert field to RouterDesc using EmbeddedCert
logic.
Unfortunately, it requires some code gymnastics similar to the (not yet
merged) identity-ed25519 certificates, which we also outlined in a
comment of a previous commit in the branch. Long story short: The
legacy parser and parse2 do not like to co-exist in the same scope due
to the self-consuming tor-cert verification chain of which the legacy
parser makes heavy use.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit modifies the legacy happy families extractor to also return
KeyUnknownCert while adding a comment explaining on why this will be
required.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit splits the inner .map() function of the happy families
extractor in the legacy parser.
In the next commit, we will return both of these variables separately,
but for now this change has no functional change and only looks
redundant.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | | |
We will change the type in the next commit and this will make auditing
the next commits easier.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-netdoc: encoding support for `w` line in routerstatus
See merge request tpo/core/arti!3991
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3991#note_3413169
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3991#note_3413168
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
In the form of trait impls.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
For encoding, we need to represent the raw parameters.
This change is carefully arranged so that when the retain unknown feature is
disabled (ie, in clients), the per-router data structure remains the
same.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Minor change which will make the next diff clearer.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This makes the error handling a bit more regular. It will also make
the code suit our further parsing changes better.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Convert the from_net_params constructor into a TryFrom. Retain the
bespoke method for the benefit of the old parser.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Not just NetParams<i32>. We're going to want it for NetParams<u32> in
a moment.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Call the existing string encoding code.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | | |
This seems trivial enough I don't feel the need to mark it
"incomplete" even though there is no test case.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-netdoc: Store or-address in a SocketAddr
See merge request tpo/core/arti!4010
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit changes the data type of RouterDesc::or_address from
Option<(net::IPv6Addr, u16)> to Vec<net::SocketAddr>.
This is the correct behavior according to the spec, meaning I will not
give a lengthy explanation on why this is better.
Reviewers might now be questioning whether the spec is wrong and/or if
this is a dangerous change, as Arti used to only extract the first IPv6
address and CTor doing a similar thing.
Following an IRC discussion with nickm@, we came to the conclusion that
both implementation techniques are right. It is okay for the document
to hold multiple addresses, it is okay for the implementation to ignore
all but the first (IPv6 address). What is not okay however, is for an
implementation to reject documents with multiple addresses.
Besides, router descriptors are not used in the existing code for
selecting the address of a relay, meaning this change has very little
practical meaning.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
tor-cert: Derive Eq on CertifiedKey
See merge request tpo/core/arti!4021
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit derives PartialEq and Eq on CertifiedKey and UnrecognizedKey
in tor-cert. We will need this later for ntor cross certificates in
tor-netdoc.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-netdoc: Sort out most remaining structural parts of network status
See merge request tpo/core/arti!3985
|
| | | | | |
| | | | |
| | | | |
| | | | | |
I unwrapped this for conflict resolution.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As pointed out in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3985#note_3413185
this was a duplicate.
The new NoFurtherArguments
* Implements encoding
* Implements more traits
* Is in the right module (types::misc - it's not just for parsing)
* Has a slightly better name
* Had an open-coded parsing impl (which we now replace)
* Had minor differences to docs (so we add a line to NoFurtherArguments)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3985#note_3413184
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3985#note_3413183
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3985#note_3413182
I left the word "fixed" in some of the docs and error messages, where
it seemed to make sense.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Replacing poc's. The new define_fixed_string macro is really helping
here.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Defining a struct gives us a place to hang the documentation, and
avoids an accidentally-exhaustive tuple.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is more code than the poc version but much of the extra is
documentation, and it seems much less magical this way.
We still need a handwritten parser for plain consensuses, sadly.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The order of arguments of poc's ns_type macro is different to that of
the real code. This is very confusing!
However, the type is correct, once we've added the singleton signature
for votes.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We're going to need this for type-driven parsing of the
necessarily-absent flavour argument in a vote's
`network-status-version`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will let us (re)use the existing signature checking code with the
parse2 type, since we'll be able to make a SignatureGroup out of a
parse2'd UnverifiedNetworkStatus.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will allow it to be a replacement inside `SignatureHashes`.
Keeping the fields private seems to have been an oversight.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is the whole of the footer section, with docs, appropriate
derives, and so on.
|