| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The affected crates follow our regular versioning.
They all get bumped to 0.26.0.
Done with
```
for crate in $(./maint/list_crates |grep '^arti-\|tor-' ); do
cargo set-version --bump minor -p $crate;
done
```
|
| |\
| |
| |
| |
| | |
clippy: deny `mod_module_files`
See merge request tpo/core/arti!2689
|
| | |
| |
| |
| |
| |
| | |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |/ |
|
| |
|
|
| |
(fmt).
|
| |
|
|
| |
Part of #1769
|
| |
|
|
|
| |
This time, we make explicit that it is a _base_ resolver,
and that it is client-only.
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.25.0
done
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The non-{arti-,tor-} crates are:
```
./maint/list_crates | rg -v '^(tor|arti)'
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
hashx
equix
caret
fs-mistrust
safelog
retry-error
```
We split them in the following categories:
* crates with no changes (no version bumps):
```
maint/changed_crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change" | grep -v '\(tor\|arti\)-'
oneshot-fused-workaround: No change.
test-temp-dir: No change.
caret: No change.
```
* crates that only have non-functional changes (bump the patch version):
- slotmap-careful
- fslock-guard
- hashx
- equix
- fs-mistrust
- safelog
- retry-error
* crates where APIs were broken (bump minor):
None
The bumps from this commit were created using this script:
```
PATCH="
slotmap-careful
fslock-guard
hashx
equix
fs-mistrust
safelog
retry-error
"
for crate in $PATCH; do
cargo set-version --bump patch -p $crate;
done
```
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the hs-pow, hs-pow-full, hs-pow-v1, pow-v1, and pow-full
features with a single hs-pow-full feature.
It's possible that in the future we will want to split different schemes
into different features, but we can do that when it comes up.
For now, having this as a single flag makes it clearer what's going on,
since the previous thing was not actually expressive enough to capture
some things we care about (like "at least one pow scheme is enabled"
that works in a future-compatible way).
This change is not semver breaking since it's a experimental feature.
Related: #1751
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Rather than using `arti_client::config::path_resolver()`, third-party
code can get the path resolver using `TorClientConfig`s
`AsRef<CfgPathResolver>` impl instead.
|
| | |
|
| |
|
|
| |
Also updated to use the `PATH_RESOLVER` resolver.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big change across multiple crates since there isn't a good way
to break it up.
This changes the signature of `CfgPath::path` to:
```
pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> {
```
Making this change means that our global `CfgPathResolver` needs to be
stored in the 'arti-client' library instead of `tor-config-path`, and
must be passed through to anything that calls `path` to expand the
variables.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-hscrypto: Abolish the HasKind impl of HsIdParseError.
Closes #1483
See merge request tpo/core/arti!2607
|
| | |
| |
| |
| |
| | |
We only ever return `BadOnionAddress` is we are asked to connect to a
.onion address that doesn't parse.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also changes the `ErrorKind` of `BadOnionAddress` to
`ForbbiddenStreamTarget`.
See context in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2246#note_3045683
Closes #1483
|
| |/
|
|
|
| |
Also updated other packages to get `CfgPath` directly from
`tor-config-path' instead of 'tor-config'.
|
| |\
| |
| |
| |
| | |
Version bumps for release of 1.3.0
See merge request tpo/core/arti!2599
|
| | |
| |
| |
| |
| | |
cargo set-version --bump=patch -p slotmap-careful
cargo set-version --bump=patch -p safelog
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
cargo set-version -p tor-async-utils 0.24.0
cargo set-version -p tor-basic-utils 0.24.0
cargo set-version -p tor-bytes 0.24.0
cargo set-version -p tor-cell 0.24.0
cargo set-version -p tor-cert 0.24.0
cargo set-version -p tor-chanmgr 0.24.0
cargo set-version -p tor-checkable 0.24.0
cargo set-version -p tor-circmgr 0.24.0
cargo set-version -p tor-config 0.24.0
cargo set-version -p tor-config-path 0.24.0
cargo set-version -p tor-consdiff 0.24.0
cargo set-version -p tor-dirclient 0.24.0
cargo set-version -p tor-dirmgr 0.24.0
cargo set-version -p tor-error 0.24.0
cargo set-version -p tor-general-addr 0.24.0
cargo set-version -p tor-geoip 0.24.0
cargo set-version -p tor-guardmgr 0.24.0
cargo set-version -p tor-hsclient 0.24.0
cargo set-version -p tor-hscrypto 0.24.0
cargo set-version -p tor-hsrproxy 0.24.0
cargo set-version -p tor-hsservice 0.24.0
cargo set-version -p tor-key-forge 0.24.0
cargo set-version -p tor-keymgr 0.24.0
cargo set-version -p tor-linkspec 0.24.0
cargo set-version -p tor-llcrypto 0.24.0
cargo set-version -p tor-log-ratelim 0.24.0
cargo set-version -p tor-memquota 0.24.0
cargo set-version -p tor-netdir 0.24.0
cargo set-version -p tor-netdoc 0.24.0
cargo set-version -p tor-persist 0.24.0
cargo set-version -p tor-proto 0.24.0
cargo set-version -p tor-protover 0.24.0
cargo set-version -p tor-ptmgr 0.24.0
cargo set-version -p tor-relay-crypto 0.24.0
cargo set-version -p tor-relay-selection 0.24.0
cargo set-version -p tor-rpcbase 0.24.0
cargo set-version -p tor-rtcompat 0.24.0
cargo set-version -p tor-rtmock 0.24.0
cargo set-version -p tor-socksproto 0.24.0
cargo set-version -p tor-units 0.24.0
cargo set-version -p arti-client 0.24.0
cargo set-version -p arti-relay 0.24.0
cargo set-version -p arti-rpc-client-core 0.24.0
cargo set-version -p arti-rpcserver 0.24.0
|
| | |
| |
| |
| | |
Manual fixup. I filed #1719 about the fact that I had to do this.
|
| | |
| |
| |
| |
| |
| |
| | |
This is output from
nailing-cargo -Eu run -p fixup-features Cargo.toml
There are some formatting glitches which I'll fix in a moment.
|
| |/ |
|
| |
|
|
| |
Mark it no longer experimental, but part of full. And document it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This new feature lets us provide the "enable these options which are
needed to make the tests pass" featrure, which is different for each
of the afflicted crates. Then we can test these crates
tor-hsservice
arti
arti-client
which minimal features.
This will be important in a moment, as we're going to want to be
relying on actually minimal features tests in arti cfg.rs.
|
| |
|
|
|
|
|
| |
Now
cargo check --workspace --no-default-features --all-targets
cargo build -p arti --no-default-features --features=memquota,tokio,native-tls
are both clean.
|
| |\
| |
| |
| |
| | |
memquota features, preparation
See merge request tpo/core/arti!2545
|
| | |
| |
| |
| |
| |
| |
| | |
This will allow us to make `tor-memquota/memquota` enabled by default,
without forcing it to be compiled in everywhere.
I don't change that in this MR, though.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
rpc spec: Start to document method naming convention
Closes #1678
See merge request tpo/core/arti!2539
|
| | |
| |
| |
| | |
Closes #1678.
|
| | |
| |
| |
| | |
Fixes a TODO.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In this design, the thin multiplexing layer between PoW types is always
available when onion services are in use, but the specific pow schemes
(and their dependency libraries) are gated by crate features everywhere.
There are now no new cfg() gates.
When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines
into an empty type (so clients know a PoW scheme exists that might be
supported if they were configured differently). We currently don't save
the contents of unknown hsdesc items.
On the relaycell side, the hs ext module already sets a strong precedent
for keeping unrecognized data as a byte vec, and it doesn't provide a
good way to signal soft parse errors like unrecognized optional
extensions. There, the `v1` type is completely optional, and services
lacking a pow scheme suggested by a client would see one of these
'unrecognized' blobs. This isn't necessarily helpful but it fits the
rest of the design.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
My previous strategy here was to try and centralize hspow in one crate,
writing it like a self-contained feature. That introduced friction in
the data types, prompting the use of simplistic types at the netdoc/cell
layers and full-featured types in the optional modules.
This changes tactics, dissolving the low-level parts of tor-hspow into
tor-hscrypto and the high-level parts into hsclient/hsservice. Full
featured types are used everywhere now, but the tradeoff is that
compile-time configurability is a lot more pervasive. Anything that
knows about PoW types at all needs to be fully configured out. I took
this opportunity to try a more complete set of crate features, allowing
users to configure individual PoW schemes.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| |/
|
|
|
|
|
|
| |
This adds a module to tor-hspow for version-independent client logic.
The entire module and its invocations are disabled unless the new
"hs-pow" compile time feature is set.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
|
| |
This broke because `tor_keymgr::config::arti` was moved to
`tor_keymgr::config`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This deduplicates the keymgr building logic in preparation for
supporting C Tor keystores (building the keymgr in a central place makes
things a bit easier, because regardless of the `kind` of the primary
keystore, we will need to extend the `KeyMgrBuilder` with the configured
secondary `ctor` keystores, if any).
|