| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3139#note_3238496
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3139#note_3238495
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We don't need this now; we can just write the impl in per_species.rs.
Formatting will be fixed in a moment.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
These two files were largely identical.
Move the common text to per_species.rs, and fix a couple of imports so
that it still compiles.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Not having the flavour in the type name is a shame, but we probably
don't want to resort to generating the docs with macros.
Part of making these two files largely identical.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Part of making these two files largely identical.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Move the implementation to the trait method which then becomes
completely identical in both files.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Part of making ns.rs and md.rs largely identical.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Part of making these two files largely identical.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In the species-specific files ns.rs and md.rs, use the unqualified
name; re-export it with the new macro.
We are working towards making these two files largely identical.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This will let us deduplicate a fair amount of code, and also will let
us support votes as well as ns and md consensuses.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Our features are generally kebab-case, and this is the way it's
documented.
Retain the old name for compatibility.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
Cut-and-paste error, I think.
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | | |
More PoW miscellania
See merge request tpo/core/arti!3132
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This also make this check a error rather than a warning.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This caps the PoW effort during sorting, rather than at intake.
This allows us to record efforts that are capped in our metrics
histogram while only recording metrics after the PoW solve has actually
been verified.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Three is a concern that a DegradedReachable status could overwrite a
previous Broken status. A nicer solution could be to add a function to
StatusSender that only will change the status to a "more or equally
severe" status.
However, I am a little dubious about using the DegradedReachable status
for PoW in general, since it has a better documented meaning for IPTs
than it does for PoW.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We do in fact need multiple locations to hold the sender.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Now that this is public, this is prudent.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I'm not 100% on this being here, it seems like it might want to be a
option for all onion services, rather than per-service. However, this is
good enough for now.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This config option doesn't really apply to Prop 362 (which is what's
implemented in Arti), as far as I can tell.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I have thought about this and come to the conclusion (which is what I
suspected when I wrote it) that the current behaviour is correct.
The attack described is completely impractical (the space of nonces is
very large), and checking whether a nonce is a replay is cheaper than
verifying a PoW solve, so we want to do that first.
Splitting this into something like the following:
* Check replay log without updating
* Check that solve is valid
* Update replay log
Would require adding a somewhat dangerous API to the ReplayLog, and
requires doing more work per request for something that isn't even a
practical attack, AFAICT.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We restored the seeds, but doing so is counterproductive if we don't
also recreate the verifiers needed to check solves for those seeds.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This does not currently allow this option to be changed at runtime,
although the code is structured so that allowing it to be changed at
runtime won't be too hard. This is tracked by #2082.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
MockExecutor now supports the features needed for this test to work.
|
| | | | | | | |
|
