| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| | |
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
| |
These helpers seem potentially broadly useful, and only really
discoverable if they're here.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Now
cargo check --workspace --no-default-features --all-targets
cargo build -p arti --no-default-features --features=memquota,tokio,native-tls
are both clean.
|
| |
|
|
|
| |
These are the call sites where using this fucntion is correct.
(Outside tor-rtmock, which we'll do separately.)
|
| |
|
|
|
|
|
| |
We are about to need this in `tor-keymgr`, where we're about to add a
config for C Tor service keystores (the C Tor keystore config will have
an associated `HsNickname` that specifies which of the arti hidden
services it's supposed to be used with).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Previously, arti's primary keystore was referred to as its "default"
keystore. However, "default" is inaccurate here: there is no way to
meaningfully override this "default" (the "default" store acts as the
main keystore). Throughout the codebase, we query all keystores for keys
(including the secondary ones), but only ever write to the
default/primary keystore. This is OK for now, because it enables us to
have one mutable keystore, and multiple secondary, read-only stores.
|
| |
|
|
| |
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)
|
| |
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
Bug 1613: Add support for inserting externally generated and removing arbitrary service discovery keys
Closes #1613
See merge request tpo/core/arti!2396
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
tor-hsservice: Improve descriptor publisher status reporting
Closes #1216 and #1572
See merge request tpo/core/arti!2397
|
| | |
| |
| |
| | |
This is already implemented.
|
| |/
|
|
|
|
|
|
|
|
| |
There are three places where we query the KeyMgr for an `HsIdKeypair` but all
we really need is the public part. This commit changes those three callsites
to instead use `get::<HsIdKey>`.
This relies on the previous commit, which makes sure that a request for an
`HsIdKey` will always succeed if the keystore has a `HsIdKeypair` with the
same service nickname.
|
| | |
|
| |
|
|
|
|
| |
We now create the authorized_clients in the publisher (we don't need the
authorized_clients anywhere else, so it makes little sense to keep them
in `RunningOnionService`).
|
| | |
|
| |
|
|
|
|
| |
MAX_RESTRICTED_DISCOVERY_CLIENTS.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2266#note_3051758
|
| |
|
|
| |
descriptor.
|
| | |
|
| |
|
|
| |
Closes #1490
|
| |
|
|
| |
Includes both `cargo fmt` and some manual code motion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a mostly-unnecessary struct holding the state of an
`OnionService` or `RunningOnionService`. It only exists because I wanted
to reduce the duplication of the `OnionService` and
`RunningOnionService` fields.
I am removing it because `OnionService` will soon become a builder, and
this inner structure is making it difficult to create an ergonomic
builder API (if we keep `OnionServiceState`, the builder fields won't
map 1:1 to the fields of the build `OnionService` type).
Note: this commit intentionally a bit misformatted to make reviewing
easier. The reformatting will come in a future commit.
|
| |
|
|
| |
This commit is automatically generated.
|
| |
|
|
| |
RunningOnionService::status_events()
|
| | |
|
| |
|
|
|
| |
These are mostly about explicitly linking to things that were
already in scope.
|
| |
|
|
|
| |
This alphabetises the imports, ready for us to do some more manual
tidying.
|
| | |
|
| | |
|
| |
|
|
| |
This may fix some bug or other.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The `OnionServiceStatus` API can now report errors coming from
`IptManager`.
Part of #1083
|
| |
|
|
|
| |
Introduce the crate, move the code motion, and make minimal necessary
changes.
|