| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | | |
This reduces clutter some more.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is in the use's at the top of the file. If we `use super::*`
(like we do in the newer modules): the code can get a lot more
readable.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Test the parsing and printing success cases.
Given that the parsing implementation is just a wrapper around B16's,
we don't need explicit tests for that.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Make this a public BytesTransparent newtype like B64, implementing all
the same traits etc.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
On reflection, and looking at the test cases, I think the name `B16`
should refer to the lowercase version. I'll introduce a type for
uppercase in a moment.
Test the display implementation.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Replace the open-coded .parse() calls with a closure.
This will let us test round trips, other types, etc., for each pairs
of test values.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Firstly, make its field pub.
Secondly, make the into_array method crate-private. It has a
crate-specific (albeit public) error type, The same basic effect can
be achieved with methods from std on arrays and slices.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Make this type public.
The new macro call means this type now implements many more traits.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I think these are all the traits that a parsing/printing newtype
adapter ought to implement.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Actually make the macro be a proper d-d macro. Replace uses of .0
with $fname, B64 with $ftype, etc.
No functional change in this commit.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Break various open-coded impls on B64 into this macro. That will let
us reuse this code for other types, making all these bytes wrappers
similar to each other.
In this commit, we just move the code. The macro is wrong because it
ought to refer to $ttype and so on. Review with git show --color-moved.
No functional change in this commit.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is slightly more logical and will make the next commit slightly
easier to read.
|
| |/ / /
| | |
| | |
| | | |
This will reduce some duplication and simplify some macrology.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Tweak TunnelId and TunnelScopedCircId Display impls
See merge request tpo/core/arti!3875
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Circuit IDs (UniqId) are displayed as "Circ <x>.<y>".
Prior to this MR, these TunnelScopedCircId's were displayed as
"Circ <t>.<x>.<y>" where t is the integer tunnel ID. This made corresponding
logs a bit confusing as to why some "Circ" identifiers had two parts and
some have three, and didn't make clear that the "<x>.<y>" part of the latter
were comparable with the two-part UniqIds.
The previous commit effectively changes the latter to
"Circ Tunnel <t>.<x>.<y>", which is still a bit confusing.
This commit changes the display of TunnelScopedCircId's to "Circ <x>.<y>
(Tunnel <t>)", which makes the distinction between the circuit and
tunnel IDs clearer.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is akin to how circuit `UniqId`'s are prefixed with "Circ", and
helps clarify logs where it isn't always clear from context whether a
tunnel ID or circuit ID is being displayed.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-netdoc: ContactInfo
See merge request tpo/core/arti!3866
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Otherwise you might, for example, receive a String from a config file,
JSON API submission, RPC call, or whatever, containing a newline, and
then encode it into a netdoc giving a syntax error or, worse,
smuggling additional items into the document!
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Otherwise the cfg_attr for the field would need to name both features.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This will be needed for ntor handshakes.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Usually, there will only be two of these.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This also updates the key rotation task to call the setter whenever the
ntor keys get updated.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This will need to be updated each time the ntor keys change.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I am about to add another one of these, so I tried to deduplicate the
impls a bit.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There is still some outstanding work here to read the lifetime and grace
period from the consensus, but that will require some bigger changes to
the rotation task.
Closes #2451
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The logic for removing and generating ntor keys is going to be slightly
different here.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This will enable us to plug in the ntor key rotation logic.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is just a wrapper over `bool` right now. It will helps us
distinguish changes to the channel auth material from changes affecting
the ntor circuit extension keys.
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
chanmgr: Validate the ChanTarget for both client and relay
Closes #2404 and #2440
See merge request tpo/core/arti!3843
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Also set a better error message when validating channel target.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This trickles down to the tor-proto channel handshake code. But, the
real need is in the channel builder in order to validate the outbound
channel target.
Fixes #2440
Signed-off-by: David Goulet <[email protected]>
|