| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2246#note_3045656
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We will use this impl for parsing the authorized clients of a hidden
service running in "restricted discovery" mode.
NB: "Restricted discovery" is the new terminology for "services that
require client authorization", i.e. services that implement "client
authorization" as described in rend-spec HS-DESC-ENC[0]. Note we haven't
fully transitioned to the new terminology yet (see #1476).
Part of #1292
[0]: https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#HS-DESC-SECOND-LAYER
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I don't think we need a separate wrapper type for displaying
`HsClientDescEncKey` keys in the "C Tor format"
(`<auth-type>:<key-type>:<base32-encoded-public-key>`).
I think this should be the canonical string representation of
`HsClientDescEncKey`, so I'm removing the `display_authorized_client`
function and corresponding `DisplayAuthorizedHsClientDescEncKey` wrapper
type.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Update to derive-deftly 0.14
See merge request tpo/core/arti!2241
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This removes the deprecated syntaxes. Updating now will prevent us
re-introducing the old syntaxes, which we updated in arti!2209.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix or allow warnings that show up in beta
See merge request tpo/core/arti!2244
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
See
https://github.com/rust-lang/rust-clippy/issues/13001
I think it's OK to change this in our tree, nevertheless.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Sadly, rustc seems to want us to mark this allow in several places.
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
I'm not sure how to resolve these. See #1467.
We ought to fix them before they propagate to +stable, particularly
since after !2242 they'll break CI.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix markdown quoting and guard against regressions
See merge request tpo/core/arti!2242
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes:
warning: unclosed HTML tag `FILE`
--> crates/arti/src/subcommands/hsc.rs:56:33
|
56 | /// Write the public key to <FILE>. Use - to write to stdout
| ^^^^^^
|
= note: `#[warn(rustdoc::invalid_html_tags)]` on by default
|
| |/ / /
| | |
| | |
| | |
| | | |
This is not used anywhere. It's not clear to we why it exists and I
think we can safely delete it.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Fix two TODO ticket numbers
See merge request tpo/core/arti!2224
|
| | | |
| | |
| | |
| | |
| | | |
I seem to have mistyped this ticket number. We meant #1397
aka "Circuit reactor isn't great", not some release ticket.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Make TAP keys optional when parsing documents.
See merge request tpo/core/arti!2227
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is the client-side part of phase 1 for proposal 350,
which will eventually remove TAP completely from the Tor network.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `arti hsc prepare-service-discovery-key` command is now
`arti hsc get-key [--key-type=service-discovery]`.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2212#note_3042903
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |
|
| | |
|