| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
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: Enable the keymgr feature by default.
See merge request tpo/core/arti!2428
|
| |/ /
| |
| |
| | |
`tor-keymgr` users now get the real keymgr implementation by default.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-keymgr: put ephemeral keystore behind experimental "ephemeral-keystore" feature
See merge request tpo/core/arti!2426
|
| |/ /
| |
| |
| | |
Feature is named "ephemeral-keystore".
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
arti: Allow running hidden services with SOCKS/DNS proxying disabled.
Closes #1569
See merge request tpo/core/arti!2423
|
| | | |
| | |
| | |
| | | |
This tests that #1569 works.
|
| | | |
| | |
| | |
| | | |
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.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
And remove the rest of the now-obsolete text.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
All of this is now documented in the lib.rs.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This sentence is very important piece of overall explanation, but
didn't make it into the crate level docs.
|
| | | | |
| | | |
| | | |
| | | | |
All of this is now implemented. Delete the obsolete sketch.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
arti: Add subcommand for generating service identity keys
Closes #1621
See merge request tpo/core/arti!2419
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
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()`.
|