| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
arti: Add hsc subcommands for key rotation and deletion
Closes #1475
See merge request tpo/core/arti!2435
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2435#note_3080452
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This new feature is experimental.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Closes #1475
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Part of #1475
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will be reused for `arti hsc key rotate`, which also outputs
the public key.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Closes #1619
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
tor-key-forge: encapsulate `define_ed25519_keypair` macro dependencies
See merge request tpo/core/arti!2433
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This re-exports the types/traits needed by the `define_ed25519_keypair`
macro so that the macro caller doesn't need to import a bunch of extra
packages in its Cargo.toml that it doesn't use, and so that the caller
doesn't need a `use prelude::*` before invoking the macro. This makes
the macro nicer to use for the caller, and should prevent the macro from
causing "cannot find ... in this scope" errors.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I am deprecating the old `hsc get-key` subcommand in favor of the new
`hsc key get` subcommand. This is because I plan to implement the rest
of the key management functionality (key deletion, rotation, etc.) as
subcommands of the `hsc key` command. The alternative would be to add a
new distinct top-level `hsc rotate-key`, `hsc remove-key`, etc.
subcommand alongside the existing `hsc get-key` command (which IMO is
less nice than the alternative I'm proposing).
|
| | | | |
| | | |
| | | |
| | | | |
These will be reused by a future `key rotate` subcommand.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise, if/when we add support for other `KeyType`s we risk
forgetting to update the rest of the implementation.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
The client will be used by future subcommands too, not just
`prepare_service_discovery_key`.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
relay: Declare keys and add a KeyMgr to TorRelay
Closes #1604
See merge request tpo/core/arti!2411
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
A relay can't operate without a KeyMgr so enable it by default from the
tor-keymgr crate.
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: David Goulet <[email protected]>
|
| | | |
| | |
| | |
| | | |
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.
|
| | | | | |
|
| | | | | |
|