| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| | |
This turns out not to be necessary.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
I hadn't been sure that we wanted to do this, since arti is
forgiving about its inputs, but IIRC Diziet was in favor of this,
and it _does_ make it easier to write tests.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-memquota: HasMemoryCost trait, and type-safe methods
See merge request tpo/core/arti!2282
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Trying to write comprehensive tests for the errors showed that these
impls were missing.
|
| | | |
| | |
| | |
| | | |
This will make testing easier.
|
| | | |
| | |
| | |
| | |
| | | |
Bug found in review:
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2282#note_3051101
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Our stream wrapper is going to want this. It's fiddly enough that
doing it as a standalone facility seems sensible.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
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
|
