| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the Arti key store would store x25519 secret keys as ed25519
OpenSSH keys, which it would convert to x25519 upon loading (using the
conversion function added in !1297 (merged)). This approach isn't good
enough though: most people will probably want to bring their existing
x25519 keys, and in order to store those in OpenSSH format, we'd need
convert them to ed25519, which is impossible (because the secret part of
an x25519 key contains a SHA512'd secret, whereas the corresponding,
"un-expanded", ed25519 secret key contains the secret itself rather than
the SHA).
Now that `ssh-key` has support for ssh keys with [custom algorithm
names], we can store x25519 in OpenSSH format directly. This commit
changes the storage format used by the keymgr for x25519 client auth
keys (from ed25519-ssh to our own custom key type with an algorithm name
of `"[email protected]"`).
Closes #936
[custom algorithm names]: https://github.com/RustCrypto/SSH/pull/136
|
| | |
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1399#note_2921505
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Some hosts were configured to log at trace level instead of the global
default (debug level). This was resulting in quite large shadow log
output.
|
| |
|
|
|
| |
This optimization doesn't seem to help much for this test; disable it to
avoid burning CI runner CPU.
|
| | |
|
| | |
|
| |
|
|
|
| |
Without this, the onion client was failing to find a guard.
We recently made this change in shadow's "tor minimal" test as well.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This commit changes the shebang in all shell scripts from absolute
paths (such as `/bin/bash` or `/usr/bin/python3`) to the `/usr/bin/env`
binary with the accompanying interpreter as it's argument.
The reason for this are as follows:
- NixOS cannot work with absolute paths
- BSD systems install their packages in /usr/local/bin
|
| |
|
|
|
| |
As of shadow 2.3, shadow can locate executables from the PATH, letting
us avoid hard-coded paths here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This was a temporary stop-gap to work around a busy loop that seemed to
happen before. I am no longer able to reproduce any such problem.
|
| |
|
|
| |
Fixes https://gitlab.torproject.org/tpo/core/arti/-/issues/174
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Apparently 5353 is commonly used for mDNS, and so counts as "already in
use" on many consumer machines.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It turns out that the clone-and-hack in tests/chutney/arti-bench
was not identical to the original in tests/chutney/setup.
I diffed the two and preferred the version from arti-bench.
|
| |
|
|
|
|
|
|
|
| |
Formerly, the "launch a chutney network" code was duplicated in
"setup" and "arti-bench", since "setup" always launched an arti
proxy, while "arti-bench" didn't want that functionality.
Now the "setup" script launches an arti proxy conditionally,
depending on whether the "proxy" argument is given.
|
| |
|
|
|
| |
This is not a replacement for a real startup protocol, but it may
help repair our CI.
|
| |
|
|
| |
Now that arti listens immediately, a very short sleep ought to do.
|
| |
|
|
|
|
|
|
|
| |
As per #309
Update all references. There is one remaining hit for
git-grep '\.sh\b'
namely "build.sh" in maint/reproducible_build, which I think is
the build script for osxcross - ie, an external project.
|
| |
|
|
|
| |
This adds `arti-bench` to the `integration` job in the CI pipelines, and
keeps around the JSON benchmark output for later comparison.
|
| |
|
|
| |
Rationale: It's good to have all of our scripts pass shellcheck.
|
| |
|
|
|
| |
Previously, this case would cause arti-bench to hang forever, trying
to bootstrap against one network while another network was running.
|
| |
|
|
| |
(An empty $RUST_LOG no output, and confuse the nickm^Wuser.)
|
| |
|
|
|
| |
shellcheck doesn't like `export FOO="$(bar)"` as one line, since it
has the possibility of missing errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new `arti-bench` crate does a simple end-to-end benchmark test
embedding Arti: it generates some random data (of configurable amount,
depending on command-line parameters), and then sends said data back and
forth via Arti (which should be configured to use a local Chutney
network).
Additionally, the benchmark can also be run via a local SOCKS5 server
(in order to benchmark the performance via a local Chutney node, for
comparison).
The `tests/chutney/arti-bench.sh` sets up and tears down Chutney as
required to make this work.
This is very much a first cut; there are many things that should
eventually get added, such as support for multiple connections, JSON
output capabilities, running multiple tests, ...
|
| |
|
|
| |
This is per a suggestion from @trinity-1686a.
|
| |
|
|
|
| |
Previously, if the arti process had died or been killed, we wouldn't
reach the point where we called "chutney stop".
|
| |
|
|
|
|
|
|
| |
If the user has CHUTNEY_PATH set, respect that value, rather than
cloning a local chutney.
Also, if we have a local chutney, then update it in case there have
been changes.
|
| |
|