| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add links to the spec, and delete explanatory text (that ought to be
in the spec, not here).
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This matches the spec.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will allow us to include this, conditionally, in the new
per-variety footer types for consensuses, without too much disruption
to the existing code.
We don't leave a compatibility alias because we're going to want a
Footer in each_variety.rs which is the actual sub-document. This old
struct isn't suitable because it doesn't have the intro item and is
just for consensuses.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to want quite a lot of this for eg network-status-version.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Client: Refactor most managers into a typestate, and construct it on bootstrap.
See merge request tpo/core/arti!4011
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Co-authored-by: gabi-250 <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Otherwise we either lose the property that you can call
launch_onion_service before bootstrapping has begun,
or we have to make launch_onion_service async.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
(This is a separate commit in order make the code movement in the
previous commit clearer.)
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will ensure that the TorClient takes its file locks immediately
on construction.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will let us be more confident in the inertness of a
not-bootstrapping TorClient, _and_ make it easier to reconfigure
things before the client is started.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Now that we have a type called "inner", and will soon have a
function to create it, we really don't want to retain this name.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We want this look to cover the whole function, to avoid weird
duplicate behavior while creating our bridge desc manager.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We'll use this to distinguish "not running" from "running",
in order to make it easier to be sure that non-bootstrapping clients
will definitely not try to connect to the network.
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | |
| | | | | | |
| | | | | | | |
Implement configuration backend logic for RPC
See merge request tpo/core/arti!4001
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | | |
Co-authored-by: gabi-250 <[email protected]>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Some of the tests used derive(Builder), which is not current
practice for our configuration.
Additionally, they didn't implement the requisite ConfigBuilder
logic to pass with the other changes in this branch.
|