| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This also fixes a couple of issues with the previous implementation:
* it enables you to watch for more than just one file/extension per
directory (each directory now has a list of filters. If any of the
filters apply to the path contained in the notify::Event, the
`FilterWatcher` notifies the listeners
* it removes the list watched files from `FileWatcher`. This makes
things a lot simpler to grok: essentially, the file watcher only
ever watches directories, notifying if an "interesting" file was
changed (in our case, the interesting files are files that have a
relevant extension, such as `.auth`, or specific configuration
files, as specified by `ConfigurationSources`).
|
| | |
| |
| |
| | |
The `FileWatcher` now uses a `postage::watch` channel under the hood.
|
| | |
| |
| |
| |
| | |
The event handler will soon be made async, so we need a handle to the
runtime.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
For the most part, this is just code motion.
The only change here is that `prepare` is no longer a method on
`FileWatcher`. This decouples `FileWatcher` from `ConfigurationSources`,
enabling us to use it to watch files and directories that aren't
configuration.
|
| |/
|
|
|
| |
The `FileWatcher` doesn't contain the channel for receiving events
anymore, and `FileWatcher::event_matched` was removed at some point.
|
| |\
| |
| |
| |
| |
| |
| | |
Use std::backtrace instead of backtrace crate
Closes #1144
See merge request tpo/core/arti!2301
|
| | |
| |
| |
| |
| | |
std::backtrace::Backtrace's Display looks the same as
backtrace_rs::Backtrace's Debug
|
| | |
| |
| |
| |
| | |
Removes resolve_backtraces from rtmock since it is no longer needed as
stdlib's backtraces automatically lazily resolve without needing a &mut.
|
| | |
| |
| |
| | |
This also adds a test for it.
|
| | | |
|
| | |
| |
| |
| | |
We can just used `build_for_arti()` here.
|
| |/
|
|
|
|
|
| |
There are two error cases where the onion name isn't printed, but
previously returned `Ok(())`.
It now returns an error to exit with a non-zero status code.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The `arti hsc` subcommand can't run without keymgr support.
Previously, it relied on `tor-keymgr/keymgr` being enabled indirectly by
its dependencies, via the `experimental` feature. We need to be able to
enable this feature in `arti` without relying on `experimental` (because
`arti hsc` will eventually be made non-experimental).
Part of #1487
|
| |
|
|
|
|
|
|
|
|
|
| |
I don't think we need a separate wrapper type for displaying
`HsClientDescEncKey` keys in the "C Tor format"
(`<auth-type>:<key-type>:<base32-encoded-public-key>`).
I think this should be the canonical string representation of
`HsClientDescEncKey`, so I'm removing the `display_authorized_client`
function and corresponding `DisplayAuthorizedHsClientDescEncKey` wrapper
type.
|
| |\
| |
| |
| |
| | |
Fix or allow warnings that show up in beta
See merge request tpo/core/arti!2244
|
| | |
| |
| |
| |
| |
| |
| | |
See
https://github.com/rust-lang/rust-clippy/issues/13001
I think it's OK to change this in our tree, nevertheless.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Fixes:
warning: unclosed HTML tag `FILE`
--> crates/arti/src/subcommands/hsc.rs:56:33
|
56 | /// Write the public key to <FILE>. Use - to write to stdout
| ^^^^^^
|
= note: `#[warn(rustdoc::invalid_html_tags)]` on by default
|
| | |
|
| |
|
|
|
|
|
| |
The `arti hsc prepare-service-discovery-key` command is now
`arti hsc get-key [--key-type=service-discovery]`.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2212#note_3042903
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an experimental `arti hsc` subcommand for managing client
state and keys. Currently, it only supports the
`prepare-service-discovery-keys` operation described in #1281 and
`doc/dev/notes/client-auth.md`.
A note on terminology: I am referring to services that encrypt the
second layer of their descriptor as running in "restricted discovery"
mode (because they can only be discovered, i.e. have their IPT points
found out, by a set of authorized clients). The corresponding client
"auth" keys, being the keys that enable the client to find out the list
of intro points, pow-params etc. of the service, are referred to as
service "discovery keys".
Alternative names I considered:
* extra descriptor encryption: accurate, but overly technical. IMO,
the CLI should be accessible to users who aren't familiar with the
nitty-gritty of the protocol
* shielded mode: good, but slightly misleading. Calling it "shielded
mode" makes it sound like a universally desirable "extra protection"
that should almost always be enabled (which is not the case). Seeing
`shielded_mode = off` in the config might be worry operators that
don't fully understand what "extra descriptor encryption" or
"shielded mode" means
* restricted mode: slightly inaccurate. It implies this mechanism is a
good substitute for conventional service-side authentication, which
it isn't (because client authorization isn't instantaneous)
Closes #1281
|
| | |
|
| |
|
|
|
| |
I propose we move each subcommand implementation to a `subcommand`
submodule.
|
| |
|
|
| |
This addresses a TODO.
|
| |\
| |
| |
| |
| | |
relay: Add relay cargo feature flag and subcommand
See merge request tpo/core/arti!2182
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the optional non default feature flag "relay" that will be used to
enable relay support of arti.
This commit also adds the "relay" subcommand to arti binary conditionnal
on the feature flag in order to have a place holder starting point.
Signed-off-by: David Goulet <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
On its own, this might not seem like a huge improvement, but it will
later let us implement these RPC methods for types that can't
reasonably implement ClientConnectionTarget.
It also serves as a proof of concept that special-method invocation
can actually work, so that we can build things like this in cases
where introducing a trait isn't practical.
Closes #1427
|
| |
|
|
| |
The context will make it possible to invoke rpc methods.
|
| | |
|
| | |
|
| |
|
|
|
| |
(We don't give an error about unrecognized namespaces (for now),
since we have no way to opt in to them.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to do this carefully, since we want our system to be
extensible with new namespaces.
First, when we are constructing an RpcMgr, we _warn_ about any
method names that are misformed.
Second, we add a test in the `arti` crate to fail if any method
names are invalid. This will only catch method names in crates that
`arti` depends on.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that Rust won't let us say
```
type ConnTarget<R> = Arc<dyn ClientConnectionTarget>;
```
because the R parameter wasn't used.
Previously we solved this by using a macro instead of a type
definition, which is ugly.
I had been thinking previously I would need to declare some kind of
additional wrapper type, and had shrunk from the verbosity. But
@diziet pointed out that I could just use a 2-tuple unconditionally.
It's still not beautiful, but it is less hideous than before.
|
| |
|
|
| |
(This is a separate commit to make the branch more readable)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The application creates these, using a new-stream-handle RPC command,
on an object that can actually create streams.
Then later, the application provides the (global) identity of one of
these objects when it's making a SOCKS connection. This causes the
object to take hold of a `DataStreamCtrl`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(These will later become objects that can receive any application
request, once we have HTTP connect.)
For now, Session and TorClient implement this trait;
but soon there will be a new type to hold on to the created
DataStreamCtrl.
There are some XXXXs here, marking code that is too ugly to live.
I should fix it before I merge this branch.
|
| |\
| |
| |
| |
| |
| |
| | |
add_warning/CI: New strategy to avoid "unexpected-cfgs" warning
Closes #1395
See merge request tpo/core/arti!2129
|
| | |
| |
| |
| | |
This commit is automatically generated.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
The rustls upgrade will solve #1377 and CVE-2024-32650.
Note that we've had to patch our RustlsProvider impl a bit in order
to keep the tests passing. See comments.
Closes #1377.
|
| |
|
|
|
|
|
| |
(Previously, nothing actually parsed these values in our
configuration.)
Closes #1333.
|
| |
|
|
| |
This will make it possible for our tests to pull them out.
|
| |
|
|
|
| |
Instead, link to documentation, and give the warning about their
security.
|
| |
|
|
| |
Closes #1124.
|
| | |
|
| |\
| |
| |
| |
| | |
Encapsulate usage of config-rs inside tor-config.
See merge request tpo/core/arti!2040
|
| | |
| |
| |
| | |
This will let us replace Config with something better.
|