Previously, to build descriptors for hidden services with client auth
enabled, in addition to the list of authorized clients, users of
`HsDescBuilder` were required to also provide a descriptor encryption
keypair and a descriptor cookie. This was potentially dangerous and/or
error-prone, because the ephemeral encryption key and the descriptor
cookie are expected to be randomly generated and unique for each
descriptor.
This change makes `ClientAuth` private to the `hsdesc::build` module and
updates `HsDescBuilder` to build `ClientAuth`s internally. Users now
only need to provide the list of authorized client public keys.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This adds a test for an `encode -> decode -> encode` flow for a hidden
service descriptor with client authorization enabled.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
`AuthClient`s were originally meant to represent parsed `auth-client`
lines. In !1070, this struct was repurposed for representing individual
authorized clients in the HS descriptor encoder. However, hidden
services will likely use a list of public keys to represent the
authorized clients rather than a list of `AuthClient`s, as the
information from an `AuthClient` (`client_id`, `iv`, `encrypted_cookie`)
likely won't be immediately available to the hidden service.
This change updates the HS descriptor encoder to represent authorized
clients as a list of `curve25519::PublicKey`s. As such, it is now the
responsibility of the encoder to create the `client_id`, `iv`, and
`encrypted_cookie` using the available keys, the unencrypted descriptor
cookie, and HS subcredential.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
Their dependents are _not_ updated to a more recent version.
These bumped the version of a dependency that they don't expose
```
tor-rtcompat
fs-mistrust
```
This one had internal refactoring:
```
tor-netdir
```
These had trivial changes only:
```
tor-checkable
tor-ptmgr
tor-guardmgr
arti-hyper
arti-bench
arti-testing
```
I found that I had the bug where I forgot to call this function, and
reached
bad_api_usage!("The circuit launcher wasn't initialized")
The possibility of such a bug is a hazard of this API pattern.
Ian Jackson
gabi-250
Nick Mathewson
Alexander Færøy
Ian Jackson