| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
See #2060.
|
| | |
|
| |
|
|
| |
Fixes #2024
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
|
| |
|
|
|
|
| |
Clippy nightly detects this problem, though earlier clippy verisons
haven't. The common element here is applying unwrap() to the result
from a write!().
|
| |\
| |
| |
| |
| | |
arti: Fix TODO + Minor Refactor
See merge request tpo/core/arti!2935
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
(This isn't a boolean, because we really don't want people ignoring
all possible required protocols.)
|
| | |
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185867
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185866
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185864
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185863
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185862
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185859
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
New cargo feature `metrics`, currently experimental.
New config option `metrics.prometheus.listen`. Uses standard `Listen`
syntax, but not every configuration is supported due to upstream
limitations.
If the config option is set, use metrics-exporter-prometheus to offer
an HTTP scrape endpoint. Or, if compiled out, fail.
Currently there are no actual metrics exported at all.
|
| |
|
|
|
| |
Otherwise it can be very confusing pushing the bump in the carpet back
and forth.
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1830.
|
| |
|
|
| |
Closes #1309.
|
| |\
| |
| |
| |
| |
| |
| | |
hsc: remove onion-address flag in favour of stdin
Closes #1630
See merge request tpo/core/arti!2861
|
| | | |
|
| | |
| |
| |
| |
| | |
* Add `quite` to the common arguments
* Substitute dialoguer in favor of `read_line` in `get_onion_address`
|
| | | |
|
| | |
| |
| |
| |
| | |
* The user will be prompted interactively for the onion-address
to prevent onion-address leaking in shell history
|
| |\ \
| |/
|/|
| |
| | |
arti: hsc-key-get: Print LF after discovery key
See merge request tpo/core/arti!2856
|
| | |
| |
| |
| |
| | |
Did not print a newline after service discovery key. Looked bad.
Prints newline now. Looks better.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Introduce ToplevelRuntime as an alias, and use it in the top-level
programs.
Now none of the principal protocol implementation code has access to
the executor's toplevel entrypoint, and can't call it by mistake.
|
| |
|
|
|
| |
Closes #1763.
Closes #1862.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Our documentation had dated to an older version of our RPC stream
code, where all streams were automatically optimistic.
But as explained, our use of "optimistic"ness in RPC stream code is
now purely internal, to make it possible to get an DataStreamCtrl.
This isn't user-visible in our rpc_conn_open_stream code.
Closes #1583
|
| |\
| |
| |
| |
| | |
rpc: Tolerate NotFound on configured connect point directory.
See merge request tpo/core/arti!2735
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
If Arti tries to bind to a directory of connect points, and that
directory isn't there, the right behavior is to treat the directory
as if it were empty. Otherwise, the user would have to create
the default connect point directory (as empty) before Arti would
start.
|
| | |
| |
| |
| |
| |
| | |
Formerly this was a conditional method argument, which is a huge
antipattern. Now it is unconditionally present, as `Option<T>` for
a type that is uninhabited when RPC isn't supported.
|
| | |
| |
| |
| |
| | |
rust-analyzer keeps re-wrapping this piece for me, even though
rustfmt doesn't complain.
|
| | |
| |
| |
| | |
Information _is_ passed to the RpcMgr, via the argument to new_connection.
|
| | |
| |
| |
| |
| | |
The RpcMgr does indirectly hold a reference to the client,
via its make_session argument.
|
| | |
| |
| |
| | |
We _do_ have error detection from this function, and have for ages.
|
| |/
|
|
|
| |
This was necessary before we had support for implementing
RPC methods on generic types.
|
| |
|
|
|
|
|
|
| |
This method doesn't actually create a new stream; it creates a
single-use client object that can be used with SOCKS to launch
a new stream, and capture an RPC object for that stream.
Closes #1664.
|