| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2102#note_3024366
|
| | | | |
| | | |
| | | |
| | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2102#note_3024370
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/|
| | |
| | | |
Closes #1353
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
tor-rpcbase: simplify invoker_ent invocation (and infer the fn type)
Closes #1380
See merge request tpo/core/arti!2103
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2103#note_3024372
I overlooked this.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Previously, one of the macros was documented to accept
`(function_expr)`, but in fact it would only accept an identifier.
Now we *do* accept any expression.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
IMO if we want flags again in the future, we should probably pick a
syntax that doesn't involve such awkward patterns.
Perhaps `$expr $( , $( $flag )* )?`.
But I think we probably won't need that feature.
|
| | | |
| | |
| | |
| | |
| | | |
This renders the Update flag redundant.
Indeed, in this commit we mow ignore the flags.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This arm puts parens around its argument. But the other arm insists
on $func:ident, and also would capture any reasonable input.
This was probably something to do with the (func_expr) syntax. We
don't need to *fix* this macrology, because in a moment the whole
macro can be made to take $func:expr.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-guardmgr: Temporarily reintroduce VanguardConfig.
Closes #1272
See merge request tpo/core/arti!2099
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The tests need to be updated now that the `VanguardMode` is read from
the config rather than the consensus.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As discussed on #tor-dev, I'm reintroducing `VanguardConfig` for now.
The `VanguardConfig` specifies what mode (full/lite/disabled) the
`VanguardMgr` should run in. We currently don't have a separate modes
for HS clients and HS services.
We shouldn't actually *need* a `VanguardConfig` at all, so this is just
a (hopefully!) short- or medium-term fix until we sort out #1382 (which
might involve making breaking changes to our `reconfigure()` APIs).
Closes #1272
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`VanguardParams` already contains the `vanguards_enabled` and
`vanguards_hs_service` `VanguardMode` params.
We still intend to abolish `VanguardConfig` in favour of deriving the
`VanguardMode` from the consensus params (#1382), but this is not the
right place for such a TODO.
|
| |/ / /
| | |
| | |
| | | |
None of these should be unused anymore.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Add LGPL-3.0 file
Closes #1375
See merge request tpo/core/arti!2094
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is the simplest way to get this included during "cargo publish",
which is necessary.
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2094#note_3021187
|
| | |/
| |
| |
| |
| |
| | |
This is required by the LGPL.
Fixes #1375.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor_memtrack: Soup up DropBomb. make into its own module, and add more tests
Closes #1381
See merge request tpo/core/arti!2100
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
In addition to the in-module, switchable, tests, I have done an ad-hoc
test, removing the bulk of the accounting from
Participation::release_qty, it crashes in a test as expected.
|
| | | |
| | |
| | |
| | | |
We're going to want this in other places.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
In addition to the in-module, switchable, tests, I have done an ad-hoc
test, removing the Drop impl for Participation, and it crashes in a
test as expected.
|
| | | |
| | |
| | |
| | | |
This will be used by refcount and bookkeeping.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
And make it testable.
In addition to the in-module tests, I have done an ad-hoc test,
removing the .promise call from deferred_drop, and it does panic in
the test cawe as desired.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Circuit reactor: document some requirements and assumptions
Closes #1373
See merge request tpo/core/arti!2089
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are some tricky bits here that implicitly assume particular
behavior in other bits for correctness. Document these requirements and
assumptions.
Fixes arti#1373
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Fix dead code warnings with Rust beta
See merge request tpo/core/arti!2098
|
| | | |
| | |
| | |
| | | |
This seems to be used only in tests, since at least 2022.
|
| | | |
| | |
| | |
| | | |
This had somehow got duplicated; remove the one in derive.rs.
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| | |
tor-circmgr: Loop until we run out of circuits to launch.
See merge request tpo/core/arti!2101
|
| |/
|
|
|
| |
Previously this would only loop `n_to_launch - 1` times, so the pool
was always 1 circuit short of the `n_to_launch` target.
|
| |\
| |
| |
| |
| |
| |
| | |
Clean up various nightly clippy warnings
Closes #1379
See merge request tpo/core/arti!2097
|
| | |
| |
| |
| |
| | |
Clippy prefers this idiom as potentially more efficient. It's not
critical-path, but let's let clippy have its way.
|
| | |
| |
| |
| | |
This is an actual bug. Closes #1379.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The old code produced a warning from clippy nightly; we may as well
update to use the new associated consts. (They've been there since
Rust 1.4x.)
|
| | | |
|