| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
| |
This should be an Option, to correspond to what's in IptSet.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Begin working on configuration logic for onion services
See merge request tpo/core/arti!1557
|
| | |
| |
| |
| | |
Note a few issues encountered while doing so.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Put a last_descriptor_expiry_including_slop into the IptSet.
Define who is responsible for which data.
The code at the sites that interacts with this needs to be bodged, to
make it still compile. That code is wrong, and the new API for
sharing the state doesn't exist yet.
|
| | |
| |
| |
| |
| | |
This is going to be complicated enough we probably want it split out
of the publisher.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Weirdly, rustdoc says
189 | /// TODO HSS surely this should be [`tor_proto::crypto::handshake::ntor::NtorSecretKey`] ?
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `crypto` in module `tor_proto`
when it should probably complain the item is private.
Anyway, we can't link to it, so don't.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937979
|
| | |
| |
| |
| |
| | |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937978
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937976
If we're publishing with Durations, then we can use Instant at least
while everything remains in-core.
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937976
|
| | |
| |
| |
| |
| | |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937971
|
| | |
| |
| |
| |
| | |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937970
|
| | |
| |
| |
| |
| | |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937969
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
I'm going to want to reuse this, and it makes the code clearer at the
one call site already.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the key material to `struct Ipt`, and add some code to generate
it.
However, this is all rather unsatisfactory. I got a bit lost in the
maze of 25519 key types, and neded up making a provisional dummy
`NtorKeyPair` type, which will need to be deleted again.
And, I wasn't able to generate K_hs_ipt_sid because of a mismatch in
Rng traits, which seems to be caused by us not properly wrapping up
the underlying crypto key types ?
At least the warts seem to be fairly localised.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Replace the publish_set closure (whose body is just TODOs right now)
with a proper function.
Change the type of the publication set to be Option<publish::IptSet>,
like the publisher now wants.
The value of the enum IptSetStatus is now no longer reified; instead,
these situations are the three branches of an if, and described in
comments.
|
| | |
| |
| |
| |
| |
| | |
Previous code review comments suggested this variable would be better
with a name that more clearly distinguished it from (say) something
containing `Relay`s.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the expiry time (as wall clock time) to publish::IptSet.
The manager is in a good position to know this information.
Provide constants that will be used (for now) for actually calculating
the expiry times.
(Right now the part where the expiry time would actually be calculated
doesn't exist, but it will come soon.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move ipt_mgr::IptSetToPublish to be publish::IptSet, and use it
everywhere appropriate.
Define descriptor::Ipt to be an IntroPointDesc from tor_netdoc.
The manager will have all the information to produce these,
so it will be convenient to simply hand them, pre-canned, to the
publisher.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The establisher has a netdir; the manager generally doesn't. So it
will be convenient for the establisher to provide the linkspecs and so
on.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Call site as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1550#note_2936401
Plus a TODO comment with an opinion from me about this API.
(Note not a TODO HSS so this is on the back burner.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
I doubt this would work yet because it will probably crash at startup
due to the unhandled error case.
Handling the error case would have a conflict with !1549 so let's do
that later.
|
| |/
|
|
|
|
|
|
| |
Break publication out of this function, which was rather long.
This does seem to make conceptual sense, now I've done it. For
example, note how the 2nd half didn't need &mut self, and so doesn't
ever `return CONTINUE;`
|
| | |
|
| |
|
|
| |
One of rustfmt's changes here is wrong. Whatever.
|
| |
|
|
|
|
|
|
| |
Now new() only has a reasonable number of arguments and removes some
repetition in the mocking arrangements in the IPT Manager.
This is the minimum amount that needs to be done in the commit that
touches both the IPT Establisher and the Manager.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1523#note_2934367
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1523#note_2934300
|
|
|
There are many TODOs and no tests, but it does compile.
|
