| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Update to rand 0.90.3 and 0.10.1
See merge request tpo/core/arti!3880
|
| | | | | | | |
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes RUSTSEC-2026-0097.
This is an unsoundness bug resulting from unexpected reentranccy if
the whole program contains both of the following
1. rand with the log feature enabled
2. logging hook that calls rand
Both of these are a priori quite unlikely. I checked with "cargo
tree" that our uses of rand do not end up depending on log, so I think
nothing in our tree enables the rand log feature.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-proto: Give our Ed25519 identity to the channel reactor
See merge request tpo/core/arti!3877
|
| | | | | | | | |
|
| | | | | | | | |
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
This will be needed for ntor handshakes.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
arti-relay: Generate and rotate ntor keys
Closes #2451
See merge request tpo/core/arti!3874
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It used to be only with the feature = relay but since client can have
that feature enabled, we now validate based on channel outbound type
instead.
Related to #2440
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
Log IDs
See merge request tpo/core/arti!3872
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|