| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Now the constructor is able to return other data to the caller,
passing it through the mtracker machinery.
|
| | | |
| | |
| | |
| | |
| | | |
I just want this for a test right now, bui it seems like it would be
good to expose it publicly.
|
| | | |
| | |
| | |
| | |
| | | |
We're going to want this as the return value from an accessor
function, which cannot fail for any other reason.
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2281#note_3051105
|
| | | |
| | |
| | |
| | | |
The stream wrapper is going to want this.
|
| | | |
| | |
| | |
| | |
| | | |
There is no `p_used` here; what we meant was the very same
`ClaimedQty.`
|
| |/ / |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-netdoc: Dangerously expose annotation fields
Closes #1469
See merge request tpo/core/arti!2213
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit exposes the fields of `routerdesc::AnnotatedRouterDesc` and
`routerdesc::RouterAnnotation` with the enabled feature
`dangerous-expose-struct-fields`.
On one side, it achieves a greater consistency among the other
structures found within this module; On the other side it makes the
already public API (assuming the feature above is enabled) useable.
Fixes #1469
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a bug in `ArtiNativeKeystore`'s `Keystore::contains()`
implementation: previously, it called Path::exists() on the relative
path (built by concatenating the key specifier and the extension), so
unless your current directory happened to be the root of the keystore,
`contains()` would always return `false`.
`KeyMgr::generate` uses `Keystore::contains()` under the hood, so it
was affected by this bug too: if called `overwrite = false`, it would
misbehave and overwrite any existing keys.
Internally, we call `KeyMgr::generate` in a couple of places:
* `tor-hsservice/src/lib.rs`, to generate the `hsid` if it doesn't
already exist. This callsite is not affected by the bug, because
`KeyMgr::generate` is only called if `KeyMgr::get` returns `None`
* `tor-hsservice/src/ipt_mgr.rs`, to generate `KS_hss_ntor` and
`KS_hs_ipt_sid` keys for intro point establishment. This callsite is
also not affected (because it too calls `get()` before attempting to
`generate()`)
The bug affects any downstream users that use `KeyMgr::generate`
with a key manager backed by `ArtiNativeKeystore`.
------
`KeyMgr::get_or_generate` is not affected, even though it calls
`Keymgr::generate` (it performs a separate extra check before calling
`generate()`). (Both suffer from a known TOCTOU race, but that's a
separate matter.) As an aside, I'd like to somehow unify
`KeyMgr::get_or_generate` and `KeyMgr::get` (I've had some attempts in
the past but ended up abandoning them because the result was more
unergonomic than the existing APIs).
Part of #1492
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new assertion fails, because the implementation of
`ArtiNativeKeystore::contains()` is buggy: it calls Path::exists() on
the relative path built by concatenating the key specifier and the
extension (so unless your current directory happens to be the root of
the keystore, contains() is always going to return false).
Part of #1492
|
| |\ \
| | |
| | |
| | |
| | | |
Lower and middle levels of Arti rpc core, version 4.
See merge request tpo/core/arti!2270
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Also add a link to #1491 where we discuss it more.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
I think we'll need this again later, but for now it's redundant.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we return RpcError by default, we don't give a good way to
actually access the original error string.
(Nonetheless, we still enforce that errors can be decoded as
RpcError.)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
A bit more test coverage in tor-rpcbase
See merge request tpo/core/arti!2264
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
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.
|
| |\ \
| | |
| | |
| | |
| | | |
UnverifiedChannel: Clarify check's peer_cert
See merge request tpo/core/arti!2260
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit clarifies the documentation of the `peer_cert` parameter in
the `UnverifiedChannel::check` function, in order to reflect that it
represents the certificate presented during the ServerHello in the TLS
handshake and not in the in-protocol CERTS cell.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
This commit fixes a bug in the `ClientCirc::extend_ntor` function, which
currently returns a `Error::MissingId(Ed25519)` in the case that no RSA
identity has been found in the accompanying channel target.
This behavior is obviously wrong, because a missing RSA identity should
yield a `Error::MissingId(Rsa)`.
|
