| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Text largely from
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1034#note_2881638
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Autogenerated with rustfmt; no code changes.
This tidies up the bizarre formatting.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is getting rather confusing; simply reformtting it won't do, I
think. Also there would be much rightward drift.
So move the meat out into the new function.
(And introduce a convenience alias for its captures.)
Docs and reformatting will follow in a moment.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Explicit drops don't work. Instead, introduce a scope.
We need two scopes, actually: one where we do the initial table
wrangling, and one for the retries after relock.
So we must put the meat in a closure so we can reuse it.
And we must return the flow control as an enum. Bah, etc.
Avoid reformatting this for the moment. This makes the delta legible...
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We're going to have another function which will want this.
Leave a convenience closure to capture the runtime.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is still correct from a lock hierarchy pov. It moves the guard
relock to the end, which is going to be necessary since it is going to
have to move right outside the loop.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1034#note_2881575
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We're about to fix the comparison to treat all empty key sets as
equal.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is still not great, but it at least makes the output plausible to
read by eye.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This will allow us to test state.rs.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Like the similar thing in tor-guardmgr.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This compiles, but it cannot work yet. Nor can it conveniently be tested.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Provide a more cookied "secret keys for use to connecting to a
particular HS" type, with a builder.
This wants to use config stuff, so oughtn't to be in tor-*crypto.
The individual types remain there.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
*If* we're going to retain any HS knowledge in circmgr, it definitely
doesn't need to know about per-operation client secrets.
(Maybe there might be ambient secrets, used for .onion diversion, but
they don't need to be in this API.)
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise there has to be a state entry in the circmgr *and* a state
entry in the hs connector, for every HS. This division of
responsibilit will be confusing.
The HS code will then be more completely just a layer on top of circmgr.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Revise EstablishIntro messages so that they can generate and check their MAC and signature.
See merge request tpo/core/arti!1043
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
(I also ran them a couple billion iterations, and didn't hit
any bugs.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The old code parsed and encoded a signature and a mac... but there
was no way to actually set them properly. Now EstablishIntro is
built around an EstablishIntroBody, and has the ability to check
signatures and macs.
Because there is no way to handle one of these messages if we can't
check the signature, we no longer accept unrecognized `auth_key` types
in this message.
I've added a test to make sure that we can validate a message from the
C tor implementation, and a test to make sure we can validate our
own cells. I also had to modify the previous tests so that their
keys were well-formed.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Expose ED25519 signature length; make ValidatableEd25519Signature
implement Debug and Clone.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We'll use this to implement signature and MAC checking for
EstablishIntro cells.
|
| |\| | |
| |/ /
|/| |
| | |
| | | |
Implement most remaining HS cell types
See merge request tpo/core/arti!1038
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
These are fairly simple, since the bulk of them is just an extension
list with no supported extensions.
|