| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This requires yet more plumbing—this time, of HsCircPool and
NetDirProvider.
|
| | | |
| | |
| | |
| | |
| | | |
We need to pass around an Arc<HsCircPool<R>>, but doing so directly
would force us to make RendRequestContext parameterized on R.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we go to answer a RendRequest, we need to have a few objects
present. This commit makes sure that they're available at the
right places.
We also note a significant problem with the need for a Subcredential
here.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes a compile error introduced as a result of merging a couple of
conflicting MRs (!1611 and !1604).
This also makes the channel the publisher uses for watching for config
changes receive `Arc<OnionServiceConfig>` (rather than
`OnionServiceConfig`).
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-hsservice: Make config a watch receiver
Closes #1041
See merge request tpo/core/arti!1611
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We introduce a bug here which the next commit will fix.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Start to implement OnionService::new (part 1)
See merge request tpo/core/arti!1604
|
| | | | |
| | | |
| | | |
| | | | |
We'll use this to implement intro point persistence.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This has a lot of open questions, and won't work yet, but it
starts to show us the current level of interface mismatch between
our pieces.
|
| | | | |
| | | |
| | | |
| | | | |
This data is all duplicated in other places, or will be.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The compile error happened because there was a conflict between
arti!1603 and arti!1599:
* the patch from !1603 uses `OnionServiceConfig::encrypt_descriptor`
* !1599 removes `encrypt_descriptor` altogether
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
tor-hsservice: Descriptor publisher improvements
See merge request tpo/core/arti!1603
|
| | | | |
| | | |
| | | |
| | | | |
See https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1603#note_2944902
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous code was correct too: after uploading the descriptor, the
`PublishStatus` is not updated, because the reactor is still in a state
where it has enough information to publish descriptors. Note that simply
"being" in the `UploadScheduled` state isn't enough to trigger another
upload, because `publish_status_rx.next()` (from the `select_biased!` of
the main-loop), blocks until something triggers another state transition
(`AwaitingIpts` -> `UploadScheduled`, or even `UploadScheduled` ->
`UploadScheduled`), so while a third state is not strictly necessary, it
does help with readability.
|
| | | | |
| | | |
| | | |
| | | | |
This also documents how updates are rescheduled.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Now that we've switched to `std::sync::Mutex` many publish functions no
longer need to be async.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
`handle_ipt_change` no longer handles the new intro points: it now
handles the IPT _change_ by updating the publish state of the reactor.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't really need to keep the handles around, so let's just discard
them.
This also updates `upload_all` to propagate any errors coming from
`build_sign`.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It doesn't make sense to use an mpsc channel for rescheduling the
rate-limited uploads. If we use an mpsc channel and `upload_all` is
called multiple times in a short timespan, we will end up scheduling
more than 1 upload reattempt. So let's use postage::watch instead.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This updates the docs (and renames the channel for rescheduling
rate-limited uploads) for clarity.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't actually need an intermediate `Descriptor` struct (and keeping
a builder around doesn't make much sense either):
* the information from the onion service config can just be read from
the `config` field of the `Inner` (mutable) reactor state
* the IPT information is retrieved right before building the
descriptor
* any key information will (eventually) be read from the `KeyMgr`
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
See thread at
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1599#note_2944510
for information about why `flatten` doesn't work here.
|
| | | | |
| | | |
| | | |
| | | | |
This matches our design.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Temporarily disable descriptor encryption configuration while we
figure out how it should work (see #1028)
|
| | |/ /
|/| | |
|
| |\| |
| | |
| | |
| | |
| | | |
tor-hsservice: Implement PartialEq for HsClientDescEncKey, Anonimity, DescEncryptionConfig
See merge request tpo/core/arti!1601
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will enable the descriptor publisher to tell whether it needs to
update the descriptor.
When the publisher is notified of an `OnionServiceConfig` change, it
checks whether the `anonimity` or `encrypt_descriptor` fields have
changed. If they have, it rebuilds and republishes the descriptor
using the new values (note: the publisher changes will be implemented in
a future commit).
|
| |\ \
| |/
|/|
| |
| | |
tor-hsservice: ipt mgr: Notify Establisher to start accepting
See merge request tpo/core/arti!1598
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We're going to want to talk about this in the Mockable trait.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The call site is going to want to do something other with the selected
IPTs than just publish them.
(This seems better than putting the Establisher notification in a
function called `publish_set`.)
|