| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Overhaul art's config tests
See merge request tpo/core/arti!1320
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I think we do actually do this as part of the coverage job, but that's
not really very clear (and getting the report in that job may be
annoying).
We also do it on nightly as part of the nightly test, but that's an
"allow_fail".
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
keymgr: Fix infinite recursion in Error impl.
See merge request tpo/core/arti!1319
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
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]>
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Add Channel expiry info in ChanMgr docs
See merge request tpo/core/arti!1316
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-hsclient: Fix test race
Closes #923
See merge request tpo/core/arti!1308
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|