| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This adds an experimental `arti hsc` subcommand for managing client
state and keys. Currently, it only supports the
`prepare-service-discovery-keys` operation described in #1281 and
`doc/dev/notes/client-auth.md`.
A note on terminology: I am referring to services that encrypt the
second layer of their descriptor as running in "restricted discovery"
mode (because they can only be discovered, i.e. have their IPT points
found out, by a set of authorized clients). The corresponding client
"auth" keys, being the keys that enable the client to find out the list
of intro points, pow-params etc. of the service, are referred to as
service "discovery keys".
Alternative names I considered:
* extra descriptor encryption: accurate, but overly technical. IMO,
the CLI should be accessible to users who aren't familiar with the
nitty-gritty of the protocol
* shielded mode: good, but slightly misleading. Calling it "shielded
mode" makes it sound like a universally desirable "extra protection"
that should almost always be enabled (which is not the case). Seeing
`shielded_mode = off` in the config might be worry operators that
don't fully understand what "extra descriptor encryption" or
"shielded mode" means
* restricted mode: slightly inaccurate. It implies this mechanism is a
good substitute for conventional service-side authentication, which
it isn't (because client authorization isn't instantaneous)
Closes #1281
|
| | | | |
| | | |
| | | |
| | | | |
Part of #1281
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will enable us to implement the `arti hsc` client subcommand for
generating client auth keys (#1281).
Closes #1291
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
See #1481.
I have checked that this category exists.
|
| | | | |
| | | |
| | | |
| | | | |
cargo set-version --offline -p arti 1.2.5
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
nailing-cargo -uE set-version -p arti-client 0.20.0
nailing-cargo -uE set-version -p arti-relay 0.20.0
nailing-cargo -uE set-version -p arti-rpcserver 0.20.0
nailing-cargo -uE set-version -p tor-async-utils 0.20.0
nailing-cargo -uE set-version -p tor-basic-utils 0.20.0
nailing-cargo -uE set-version -p tor-bytes 0.20.0
nailing-cargo -uE set-version -p tor-cell 0.20.0
nailing-cargo -uE set-version -p tor-cert 0.20.0
nailing-cargo -uE set-version -p tor-chanmgr 0.20.0
nailing-cargo -uE set-version -p tor-checkable 0.20.0
nailing-cargo -uE set-version -p tor-circmgr 0.20.0
nailing-cargo -uE set-version -p tor-config 0.20.0
nailing-cargo -uE set-version -p tor-consdiff 0.20.0
nailing-cargo -uE set-version -p tor-dirclient 0.20.0
nailing-cargo -uE set-version -p tor-dirmgr 0.20.0
nailing-cargo -uE set-version -p tor-error 0.20.0
nailing-cargo -uE set-version -p tor-geoip 0.20.0
nailing-cargo -uE set-version -p tor-guardmgr 0.20.0
nailing-cargo -uE set-version -p tor-hsclient 0.20.0
nailing-cargo -uE set-version -p tor-hscrypto 0.20.0
nailing-cargo -uE set-version -p tor-hsrproxy 0.20.0
nailing-cargo -uE set-version -p tor-hsservice 0.20.0
nailing-cargo -uE set-version -p tor-keymgr 0.20.0
nailing-cargo -uE set-version -p tor-linkspec 0.20.0
nailing-cargo -uE set-version -p tor-llcrypto 0.20.0
nailing-cargo -uE set-version -p tor-log-ratelim 0.20.0
nailing-cargo -uE set-version -p tor-memquota 0.20.0
nailing-cargo -uE set-version -p tor-netdir 0.20.0
nailing-cargo -uE set-version -p tor-netdoc 0.20.0
nailing-cargo -uE set-version -p tor-persist 0.20.0
nailing-cargo -uE set-version -p tor-proto 0.20.0
nailing-cargo -uE set-version -p tor-protover 0.20.0
nailing-cargo -uE set-version -p tor-ptmgr 0.20.0
nailing-cargo -uE set-version -p tor-relay-selection 0.20.0
nailing-cargo -uE set-version -p tor-rpcbase 0.20.0
nailing-cargo -uE set-version -p tor-rtcompat 0.20.0
nailing-cargo -uE set-version -p tor-rtmock 0.20.0
nailing-cargo -uE set-version -p tor-socksproto 0.20.0
nailing-cargo -uE set-version -p tor-units 0.20.0
Each of which runs a rune like
cargo set-version --offline -p tor-units 0.20.0
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This updates the code to match the spec.
This fixes TROVE-2024-008.
Closes #1474
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This has been obsolete for a very long time.
We have already published a version with a "won't be updated" warning.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Run maint/fixup-features
See merge request tpo/core/arti!2229
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Precisely
nailing-cargo -Eu run -p fixup-features Cargo.toml
These changes are just `full` propagation. Note the `?` in the
arti-relay propagation, which is essential: we don't actually *enable*
arti-relay at all, with this.
Also, there is a formatting anomaly, which I'll fix in a moment.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p statrs
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p itertools
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We're about to update to iterools 0.13.0. We must therefore have a
version of strum which is not affected by
https://github.com/Peternator7/strum/issues/358
Precisely
git-grep -l '^strum' | xargs perl -i~ -pe 's{"0\.26"}{"0.26.3"}'
No changes to lockfile - we're already using 0.26.3, except perhaps in
the minimal versions test.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p derive-deftly
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Resolve a rustdoc warning.
See merge request tpo/core/arti!2215
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Write a README for tor-rpcbase
See merge request tpo/core/arti!2210
|
| | |/ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Name chosen to match the error kind that we're detecting.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit adds a parameter to TorClientBuilder that control how long
we should retry constructing a TorClient if we get a
LocalResourceInUse error. When this parameter is not set, we
default to 500 milliseconds for async entry points and 0
milliseconds for sync entry points.
(`LocalResourceInUse` usually means that a lockfile is held by
somebody else; but when the resource is some other type, we
typically want the same behavior anyway.)
(I really don't want to introduce delays by default for the
create_unbootstrapped case, since it previously had no delay at
all.)
There is now also an async entry point to create an unbootstrapped
TorClient.
Closes #1464.
|
| |/
|
|
|
| |
There is no actual reason to consume this type, and taking it by
reference allows us to retry.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is just code motion: moving the vanguard-specific parts of
`maybe_extend_stub_circuit()` behind the `vanguards` feature will enable
us to refactor it to use `select_middle_for_vanguard_circuit()`, which
is only available if the `vanguards` feature is enabled.
|
| | |
|
| |
|
|
|
|
| |
This is a follow up from https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2186#note_3035525
Closes #1459
|
| |
|
|
| |
There's not much to refactor about this line.
|
| | |
|
| |
|
|
|
|
| |
This test is not new (it was added in !2168), but I think it's a good
idea to annotate the tests preventing security issues with the TROVE
number and/or arti ticket they pertain to.
|
| |
|
|
|
|
|
| |
These tests should give us *some* assurance that the upcoming
`HsVanguardPathBuilder` refactoring doesn't break anything.
Part of #1459
|
| |
|
|
| |
Part of #1459
|
| | |
|
| |
|
|
|
|
| |
We will soon need these helpers outside of `tor-guardmgr` too.
This commit is mainly code motion.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tls: Support export keying material (RFC 5705)
Closes #1432
See merge request tpo/core/arti!2185
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a function to get the keying material as detailed by RFC 5705.
Because native-tls doesn't have such support, there is a place holder
panic!() for now.
This means that for the forseable future, relay would only work with
rustls until we figure out a solution for native-tls.
Closes #1432
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
dirmgr::storage: Treat a missing blob file as an absent object.
Closes #1466
See merge request tpo/core/arti!2200
|
| | |
| |
| |
| | |
SQL is case-insensitive, but it is still nice to be consistent.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch removes files from dir_blobs if they are not referenced
from the database, or if their filenames are not valid UTF-8.
(If they were not valid UTF-8, we wouldn't have put them in our
database.)
To ensure that there can't be any race conditions, we only do this
when the file is a bit old.
|
| | |
| |
| |
| |
| | |
Previously, we were putting an (optional) db.sql file and our blobs
into the same path, which is not what we do outside of our tests.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Without this, "ON DELETE CASCADE" will do nothing.
Part of fixing #1466.
|