| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Done using:
```
cargo set-version --bump patch -p arti
```
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
This currently is not implemented.
|
| |
|
|
|
|
| |
Rather than using `arti_client::config::path_resolver()`, third-party
code can get the path resolver using `TorClientConfig`s
`AsRef<CfgPathResolver>` impl instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
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
|
| | |
| |
| |
| |
| |
| |
| |
| | |
I think we should bump the minor version because of the new features,
particularly supporting .onion domains as a client by default, and the
OOM DoS resistance features (#351).
cargo set-version --offline --bump=minor -p arti
|
| | |
| |
| |
| |
| | |
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.
|
| |/
|
|
| |
It's weird that full doesn't imply default. But here we are.
|
| |
|
|
|
| |
Nothing in the changelog seems concerning. There's an MSRV bump,
but still lower than our own MSRV.
|
| |
|
|
| |
Mark it no longer experimental, but part of full. And document it.
|
| |
|
|
|
|
|
|
| |
And document the Cargo features.
This compiles in the memquota support for people who depend directly
on tor-memquota. But all our in-tree dependencies turn off default
features, so this doesn't have any effect for in-tree crates.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2561#note_3097443
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2561#note_3097442
|
| |
|
|
|
| |
Work around awkward cargo behaviour and allow us to more reliably test
disabled features, even if they're enabled by default at lower levels.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
I'm about to remove HasKind from InvokeError, which would otherwise
break this code.
These errors are all in fact internal errors, since in this context
they can only stem from incorrectly formed calls to
`invoke_special_method`.
|
| |\
| |
| |
| |
| | |
Disable a lot of dead code warnings and add a default-runtime feature in arti
See merge request tpo/core/arti!2551
|
| | |
| |
| |
| |
| |
| | |
Now one can do a minimal build with
cargo build -p arti --no-default-features --features=default-runtime
rather than needing to specify tokio,native-tls.
|
| | |
| |
| |
| |
| |
| |
| | |
Now
cargo check --workspace --no-default-features --all-targets
cargo build -p arti --no-default-features --features=memquota,tokio,native-tls
are both clean.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor-config: Use a polling watcher on non-windows platforms that don't have inotify.
Closes #1644
See merge request tpo/core/arti!2547
|
| | | |
| | |
| | |
| | | |
Part of #1644
|
| | | | |
|
| | |/
| |
| |
| |
| | |
This enables us to make use of the unfortunately-necessary test-specific
code path.
|
| |\ \
| |/
|/|
| |
| | |
arti: remove 'relay' subcommand and 'arti-relay' dependency
See merge request tpo/core/arti!2542
|
| | | |
|
| |/
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
The FreeBSD fixes were released in [`secmem-proc 0.3.4`].
Closes #1686
[`secmem-proc 0.3.4`]: https://github.com/niluxv/secmem-proc/pull/11
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The proof-of-work libraries are off by default in part because they
depend on libraries that are currently GPL licensed. This precludes
the use of this option in closed-source binaries, but here in the
open-source arti tool (or consumers that bundle the binary) it's fine.
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| |\
| |
| |
| |
| |
| |
| | |
tor-keymgr: Support reading C Tor keys.
Closes #858
See merge request tpo/core/arti!2481
|
| | |
| |
| |
| |
| |
| |
| | |
This way we have a more intuitive layout, where all C Tor keystore
configuration is under the `ctor` key.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2481#note_3090486
|
| | |
| |
| |
| | |
This enables us to build `arti` with C Tor keystore support.
|
| | |
| |
| |
| |
| | |
This is intentionally partially mis-indented to make this more
reviewable (in case the reviewer isn't using `ignore-all-space`).
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
docs: Add vanguard feature flag to README.
See merge request tpo/core/arti!2507
|
| | |
| |
| |
| |
| | |
We now support pluggable transports, so it's not true that there's no
anti-censorship support.
|
| | | |
|
| |/
|
|
|
|
|
| |
This was disabled due to lack of vanguard support. Now that we support
vanguards, we should enable this by default.
Fixes: #1402
|