| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When creating the KeyMgr, attempt to create the long-term identity key
if none are found in the KeyMgr.
Until the KeyMgr has certificate support, we can't create the
certificate. Add a TODO comment item about future work needed there.
Related to #1604
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is the first step before creating relay key definition and storing
them into a keystore.
The KeyMgr should be passed on the ChanMgr in later commit so the
ChanMgr can use it for the authenticated channel handshake.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This adds a new crate called tor-relay-crypto which is responsible for
declaring the relay keys and certificate that will be used by a relay
and stored in a KeyMgr.
This is in its own crate and considered pretty low level so other crates
can use it to access the relay keys, like tor-proto, for cryptographic
actions like channel authentication or descriptor signing.
The lower level cryptographic keys are wrapped in a higher level object
in this crate, using tor-key-forge crate, so we can have proper semantic
and strong type check on those keys so they are not misused or confused
with other keys.
At this point, the key declaration might change once the KeyMgr supports
attaching a certificate to a key. We are likely going to see more code
related to certificate creation in this crate in the future.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Implement the signature::Signer and Ed25519PublicKey trait so the
ed25519 keypair wrapper can be easily used for certificate creation.
This also adds a to_ed25519_id() so we can get a Ed25519Identity which
is an object used around.
Finally, add a prelude module as the list of imports started to grow a
bit out of control.
Part of #1604
Signed-off-by: David Goulet <[email protected]>
|
| |/ /
| |
| |
| | |
`tor-keymgr` users now get the real keymgr implementation by default.
|
| | |
| |
| |
| | |
Feature is named "ephemeral-keystore".
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
arti: Allow running hidden services with SOCKS/DNS proxying disabled.
Closes #1569
See merge request tpo/core/arti!2423
|
| | | |
| | |
| | |
| | | |
If `socks_listen` is disabled, we're not actually running in SOCKS mode.
|
| | | |
| | |
| | |
| | | |
Closes #1569
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
memquota: be more firm about avoiding panics, and tidy up docs
See merge request tpo/core/arti!2404
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Remove extraneous text, wrap it, and change to a more declarative style.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This detect possibly-panicking operations.
Empirically this lint seems rather better now.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It is not locally obvious that n_particips can't be zero, here.
Certainly if it *is* that would be state corruption, but I don't think
I can quite rule it out in the presence of a bug somewhere else.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
In these two places, underflow is statically impossible, but
demonstrating that to the compiler is probably too onerous.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This sentence is very important piece of overall explanation, but
didn't make it into the crate level docs.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-keymgr: add disk-related docs to `ArtiEphemeralKeystore`
See merge request tpo/core/arti!2424
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
Bump MSRV from 1.70 to 1.75.
See merge request tpo/core/arti!2421
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The `hss get-key` functionality was folded into `hss onion-name`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `hss get-key` subcommand is now folded into `onion-name`, which
takes a `--generate` argument which specifies whether to generate the
key if missing.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2419#note_3078068
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds a new `hss get-key` subcommand for retrieving and generating
service identity keys. The existing `hss onion-name` is now a
convenience alias for `hss get-key --generate=no --key-type=onion-name`.
Note: I am calling this new subcommand `get-key` for consistency with
its client counterpart (`hsc get-key`).
Closes #1621
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is needed because we'll soon add an `hss get-key` subcommand for
getting and/or generating a service identity key alongside `hss
onion-name` (`hss onion-name` will become a convenience around `hss
get-key --key-type=onion-name`).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This splits `onion_name` into multiple functions (which will be
repurposed for the future `hss get-key` implementation).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`hss` will soon sprout another subcommand, so I am preemptively
refactoring the `hss onion-name` implementation out of `hss::run()`.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The tests were added in !2275
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This also reexports `HsId` from the `tor-hsservice` crate.
|
| | | | | | |
|
| | |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We will soon add a new `OnionService` function for generating an HsId
for the service without launching it (#1621).
This new API will be implemented using `maybe_generate_hsid`, which will
need to take the user-provided keystore selector as an argument.
(the selector exists for future-proofing reasons; we're not yet exposing
it in the CLI, but it will be part of the new `OnionService` API)
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Bug 1612: Allow programmatic launching of onion-service with user-provided HsIdKeypair
Closes #1612
See merge request tpo/core/arti!2402
|
| | | | | |
| | | | |
| | | | |
| | | | | |
HsIdKeypair
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This defers generating an HsId until `OnionService::launch`, enabling us
to use APIs like `OnionService::onion_name` to e.g. check for the
existence of an HsId (previously, you couldn't do that because creating
an `OnionService` would auto-generate the `HsId`).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per #1247, we decided to stick with the current name.
As for the docs, they were added in !1946
|
| | |/ / /
|/| | |
| | | |
| | | | |
This has been deprecated since 1.2.6, so let's remove it.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Implement and user Reader::take_all_but()
Closes #1620
See merge request tpo/core/arti!2415
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I've used an `async{ expr }.await` pattern, to make sure that
_every_ error returned by the `loop{select!{}}` construct is
actually transformed.
|