| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was super confusing and fragile. Amongst the problems:
* Information about exceptional config keys was spread across a
number of places, manipulated in ad-hoc ways (conditional Vec
appends, etc).
* As a consequence, each exceptional table has confusing and unclear
semantics.
* It doesn't deal well with the way that cargo sometimes enables
features for dependency crates even if arti itself wouldn't demand
them; this can lead to sub-crates supporting config keys when the
tests in arti don't expect them to, causing spurious test failures.
Fix this:
* Introduce a new, systematic, way of writing information about
configuration keys that need some kind of special handling.
* Use this new approach in *both* sets of "thorough" config tests.
* Be more relaxed about deprecated keys. We don't want to tightly
couple this to absence in the supported file, I think.
* Understand more clearly the concept of keys of which we don't know,
in the current build config, whether the code is expected to
accept them.
I have tested this locally with:
for p in '-p arti' '--workspace'; do for f in '--no-default-features --features=tokio,native-tls' '--all-features' ''; do nailing-cargo test $p $f; done; done
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We *do* have a thing that works like this.
It's fragile and confusing and that's what I'm about to fix.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Bring the exciting tests together, and move some more normal tests out
of the middle.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Without this, the build fails with
cargo test --workspace --no-default-features --features=tokio,native-tls
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Fixes a warning with
cargo clippy --locked --offline --workspace --all-targets
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
If all the fields vanish, this generates a warning with
cargo clippy --locked --offline --workspace --all-targets
Fix that.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
keymgr: Implement ErrorKind for keymgr error types
See merge request tpo/core/arti!1315
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Resolve remaining dirclient HS todos
See merge request tpo/core/arti!1323
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Yes, it's 50 kilobytes, not 50 kibibytes. I double-checked this with
the C implementation and with param-spec.txt's documentation for
`HSV3MaxDescriptorSize`.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Remove support for receiving unauthenticated SENDMEs.
Closes #914
See merge request tpo/core/arti!1283
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We haven't generated these since Tor 0.3.5, which is no longer
supported on the network.
Closes #914.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
llcrypto: Implement ed25519_to_curve25519_private conversion.
See merge request tpo/core/arti!1297
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This removes the `# Availability` section from the
`convert_ed25519_to_curve25519_private` and
`convert_curve25519_to_ed25519_private` docs.
We don't generally have this sort of section anywhere else in the
codebase (we use unstable cargo-docs features to make sure items are
annotated correctly).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `convert_curve25519_to_ed25519_private` and
`convert_ed25519_to_curve25519_private` functions are now exported by
`tor-llcrypto` if the `cvt-25519` feature is enabled.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
convert_ed25519_to_curve25519_private.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds a TODO explaining how convert_ed25519_to_curve25519_private
will need to be audited when we upgrade to the latest x25519-dalek.
This also adds a `debug_assertions` and a test that ensures
`StaticSecret::from` is clamping the input (when we bump x25519-dalek,
the assertions will fail, as the latest version doesn't do clamping in
StaticSecret::from).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In `ArtiNativeKeyStore`, private keys are stored in OpenSSH format.
However, `ssh-key` (the crate we use for parsing OpenSSH keys) doesn't
support x25519 keys. As a workaround, this type of key will stored
as ed25519 and converted to x25519 upon retrieval.
This commit implements the `convert_ed25519_to_curve25519_private`
conversion function (needed by `ArtiNativeKeyStore` to support x25519
keys).
Part of #900
|
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
The `source` impl `tor_keymgr::Error` was just calling itself
recursively.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Back down x25519-dalek to 2.0.0-pre.1 from 2.0.0-rc.2
Closes #926
See merge request tpo/core/arti!1317
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
=========================
Notes from nickm:
(This differs from pinkforest's original MR: It removes the
Cargo.lock changes and the version bump on tor-llcrypto.)
Minimal Cargo.lock changes from downgrade.
(These are exactly those changes generated by running "build" and
"test".)
There are several reasons to do this:
* It's best to bump all of our dalek dependencies at once to rc.3
or later, rather than the piecemeal approach we've been stuck
with so far.
* We don't want to do this bump right now, since there are some
tricky questions about clamping we need to figure out (see
#808), and we need to make sure we get them right, and we're in
a distracted this week.
* We _do_ need to move away from 2.0.0-rc.2 right now, since
it was causing a failure in `cargo install arti`, and then it
got yanked.
Thanks to pinkforest for helping us out here and explaining all of
this!
Fixes #926.
Commit-edited-by: Nick Mathewson <[email protected]>
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Fix a use of 10ms that should have been TIMEOUT_SLOP.
2. Increase BODGE_YIELD by a factor of 5.
Now this test should tolerate being hung up for 125ms. I am hoping
that this will fix the CI failure
https://gitlab.torproject.org/Diziet/arti/-/jobs/302457
which fails at the line comparing circuit1 with circuit2a.
(I can't repro that locally.)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without this, the expiry task can end up choosing a 600s timeout
starting *after we advanced the clock*.
Fixes #923
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The provided impl for Mutex is hopeless: it prints just some internal
flags and doesn't acquire the mutex for printing purposes.
At some point we might want to factor this out as a general function
on `Arc<Mutex<...>>` but not now.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
arti-client: Mark DirProviderBuilder Send+Sync;
Closes #924
See merge request tpo/core/arti!1307
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Doing this causes TorClientBuilder to become Send. I also add a
test to ensure that TorClientBuilder remains Send in the future.
This isn't a semver break, but only because DirProviderBuilder is
marked with `experimental-api`.
Closes #924
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
netdoc: Resolve nearly all remaining TODO HS items.
See merge request tpo/core/arti!1304
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Although this Errorkind is not perfect, it is good enough.
|
| | | | | | |
|