| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Note a few issues encountered while doing so.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
For rate-limiting, we make it optional. If it isn't set, we don't
tell the intro to rate-limit.
We condense our two max-streams options into one. We had two
options here because we were looking for feature parity with C, but
I think I had misunderstood what C provides.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reactor events are no longer received on the same channel, so we
don't need the `Event` enum or the old `Publisher` APIs any more.
Svc config changes are received on a wseparate `postage::watch` channel,
whereas IPT changes are detected through the `IptsPublisherView`.
The publisher will (eventually) be informed of keystore changes through
another `postage::watch` channel.
|
| | |
| |
| |
| |
| | |
If multiple config changes happen in quick succession, we don't want the
publisher to publish a new descriptor for every single one.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This makes the publisher watch for IPT changes using the
`IptsPublisherView` added in arti#1023 (instead of waiting for an
`Event::NewIntroPoints`. The `Event` enum will soon be replaced by
multiple `postage::watch` channels, one for every type of change it
needs to react to).
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The descriptor publisher reactor was (incorrectly) only keeping track of
the "current" and "previous" time periods.
The reactor now maintains a list of all relevant time periods (obtained
from `Netdir::hs_all_time_periods`).
|
| | |
| |
| |
| |
| | |
We don't need to build the `Descriptor` for each time period (it
contains TP-agnostic information).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was based on the incorrect assumption there would be an external
source notifying the reactor of time period changes.
Time period changes will be handled in the consensus change handler of
the reactor.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1545#note_2935668
|
| |\ \
| | |
| | |
| | |
| | | |
Version bumps in preparation for today's release
See merge request tpo/core/arti!1570
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These are:
```
hashx
equix
tor-async-utils
tor-error
tor-config
tor-rtmock
tor-llcrypto
tor-bytes
tor-hscrypto
tor-hspow
tor-cert
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-netdir
tor-chanmgr
tor-guardmgr
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
arti-client
arti
```
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These are:
```
tor-dirclient
tor-ptmgr
```
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-hsservice: Fix broken doc links.
See merge request tpo/core/arti!1565
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
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_2937975
|
| | |
| |
| |
| |
| | |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1559#note_2937973
|
| | |
| |
| |
| |
| | |
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.
|