| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These don't yet attach to the rest of the ArtiConfig, or actually
launch any onion services, but they're a start.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ /
| | |
| | |
| | | |
Return a stream of requests, and document what to do with them.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-hsservice: Make the publisher not require callers to specify the hsid.
See merge request tpo/core/arti!1637
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, the descriptor publisher needed the `hsid` for logging
purposes and for deriving the blinded public keys.
This changes the publisher to log the `HsNickname` of the service
instead of the hsid, and to read the blinded keys from the keystore.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We will soon rewrite this function to load the blinded key from `KeyMgr`
(instead of deriving it from `self.hsid_key`).
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-proto: Refactor the key derivation
See merge request tpo/core/arti!1629
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit refactors the key derivation, by applying the following:
- The spaghetti slice creation with the hard-to-read boundaries got
replaced by a closure, which accepts a length, advances the seed slice
by n bytes as a side-effect, and returns the just advanced bytes
- The use of `.except` got replaced by an `.or`, with the use of the
already existing `InvalidKDFOutputLength` error, thereby removing a
potential panic (probably not reachable in runtime though)
- The conversion from a slice to a `CircuitBinding` got moved into a
`TryFrom` trait of the appropriate data structure
|
| |\ \ \ \ \
| | |/ / /
| |/| / /
| |_|/ /
|/| | | |
tor-hsservice: Fix hsdesc publisher bugs, add tests
See merge request tpo/core/arti!1634
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Not checking whether the response is successful can have unintended
consequences.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We were previously converting the RequestFailedError to a RequestError,
which discards the error source.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This fixes a clippy complexity warning. It also makes the code more
readable, IMO.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When called by `Reactor::upload_all()`, `Reactor::netdir()` deadlocks
(`netdir()` needs to acquire the `inner` lock, but `inner` is already
held by `upload_all`).
Since `netdir()` is only called in `upload_all()`, let's fix the
deadlock by inlining it at the callsite.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The publisher was stuck in the `AwaitingIpts` state because of a logic
bug in the `update_publisher_state` function.
The publisher now breaks out of the `AwaitingIpts` state upon receiving
new IPTs from the IPT manager.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The statement
```
if hsids.all(|(_hsid, period)| rings.any(|(_, _, tp)| tp == period)) {
```
had 2 bugs:
* the condition is reversed (it should be negated: we need to bail if
one of the specified `hsids` cannot be found on any of our rings)
* `rings.any()` mutates the `rings` iterator, causing
`hs_dirs_upload` to return fewer HSDirs than expected
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This renames `ReactorState` to `Real`, for consistency with `ipt_mgr`,
which calls the real version of its mockable state `Real`.
|
| | | | |
| | | |
| | | |
| | | | |
provider).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds a couple of new `HsSvcKeyRoles` for:
* `KS_hs_id` keypairs
* `KP_hs_blind_id` public keys keys
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
(The only change in these crates is that their dependencies changed.)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
These crates have had changes that do not require their dependents
to require a later version.
|
| |/ / |
|
| | |
| |
| |
| |
| | |
This commit fixes a warning in the documentation, caused by an
unresolved name.
|
| |\ \
| | |
| | |
| | |
| | | |
Upgrade several dependencies
See merge request tpo/core/arti!1626
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead of tying ourselves to a particular version of the
generic-array crate, we now always use the version re-exported by
our RustCrypto crates. This lets us avoid the possibility of
version mismatch.
(Originally I had planned to upgrade to generic-array 1.0, but then
I found that we were not actually using it.)
|