| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates are at version 0.x.y, so we don't need to distinguish
new-feature changes from other changes:
```
tor-basic-utils
fs-mistrust
tor-error
tor-geoip
tor-checkable
tor-linkspec
tor-netdoc
tor-netdir
tor-persist
tor-ptmgr
tor-hsservice
```
This crate has a breaking change, but only when the semver-breaking
feature `experimental-api` is enabled:
```
tor-config
```
This crate is at version 1.x.y, but has no new public APIs, and
therefore does not need a minor version bump:
```
arti
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates had first-order breaking changes:
```
retry-error
tor-keymgr
tor-proto
tor-hsclient
tor-rtmock
```
Additionally, these broke because they re-exposed RetryError:
```
tor-circmgr
```
Additionally, these broke because they may re-expose something from
tor-proto:
```
arti-client
tor-chanmgr
tor-dirclient
tor-dirmgr
tor-guardmgr
```
Additionally, these broke for other fiddly reasons:
`tor-ptmgr` implements traits from tor-chanmgr, which has a breaking
change above.
`arti-hyper` exposes types from arti-client in its API.
|
| | |
|
| |
|
|
|
|
| |
There was a bug in 0.10.0 that broke MacOS.
Part of #963.
|
| | |
|
| |
|
|
| |
Closes #939
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It is no longer experimental, but still not rated for security-sensitive
usage per <https://blog.torproject.org/arti_116_released/>.
|
| |\
| |
| |
| |
| |
| |
| | |
arti: Build with HS client support by default
Closes #948
See merge request tpo/core/arti!1382
|
| | |
| |
| |
| | |
Fixes #948
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes #949.
|
| |/
|
|
| |
Closes #950.
|
| |\
| |
| |
| |
| |
| |
| | |
arti: Add a `logging.time_granularity` option with 1s default.
Closes #551
See merge request tpo/core/arti!1376
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
I was unable to assure myself that tracing_subscriber could
withstand a panicking Timer, so instead I'm trying to make sure
our own LogTimer can't panic.
|
| | |
| |
| |
| |
| |
| |
| | |
This lets us provide less information in our logs: in particular, it
lets us avoid logging with microsecond precision.
Closes #551.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The original version of our panic handler would allocate a string
for the panic `Location`. But if we're panicking we'd like to keep
allocations to a minimum: so instead format the `Location`
conditionally.
This also drops a useless `std::borrow::Cow`. (The possibility of a
"Don't have a `Cow`" commit message was considered and rejected.)
|
| | | |
|
| |/
|
|
|
|
|
| |
(Also leaves installed the default handler that sends messages to
stderr.)
Closes #921.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Done with the commands below.
The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.
```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```
This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.
```
cargo set-version --bump patch -p arti
```
|
| |
|
|
|
|
|
|
|
|
| |
Done with:
```
cargo set-version --bump minor -p tor-hsclient
cargo set-version --bump minor -p arti-rpcserver
cargo set-version --bump minor -p tor-hscrypto
cargo set-version --bump minor -p tor-cell
```
|
| | |
|
| |\
| |
| |
| |
| | |
arti-client: Add keystore_dir to StorageConfig.
See merge request tpo/core/arti!1312
|
| | |
| |
| |
| |
| | |
This moves `storage.keystore_dir` to a separate `declare_exceptions`
block and explains why we have this exception.
|
| | |
| |
| |
| |
| |
| | |
Let's remove this until we figure out how the config should behave when
the `keymgr` feature is disabled (should it accept or reject
`keystore_dir = true`?)
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Mark all {hs,onion-serivce}-client features as non-experimental.
Closes #896
See merge request tpo/core/arti!1347
|
| | |/ |
|
| |/
|
|
| |
As per IRC discussion, re lack of Vanguards.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It's used for declarations only, and they should all be here.
|
| |
|
|
|
|
| |
As per discussion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1320#note_2916689
and IRC followup.
|
| |
|
|
|
|
|
| |
I think these should go in `[circuit_timing]`. That section already
has some retry parameters, so is not strictly *timing*.
This is not honoured yet.
|
| |
|
|
|
|
|
| |
We put this in `[address_filter]`.
The interaction with the corresponding stream preference is a bit
complicated. We must turn the stream pref into a `BoolOrAuto`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was super confusing and fragile. Amongst the problems:
* Information about exceptional config keys was spread across a
number of places, manipulated in ad-hoc ways (conditional Vec
appends, etc).
* As a consequence, each exceptional table has confusing and unclear
semantics.
* It doesn't deal well with the way that cargo sometimes enables
features for dependency crates even if arti itself wouldn't demand
them; this can lead to sub-crates supporting config keys when the
tests in arti don't expect them to, causing spurious test failures.
Fix this:
* Introduce a new, systematic, way of writing information about
configuration keys that need some kind of special handling.
* Use this new approach in *both* sets of "thorough" config tests.
* Be more relaxed about deprecated keys. We don't want to tightly
couple this to absence in the supported file, I think.
* Understand more clearly the concept of keys of which we don't know,
in the current build config, whether the code is expected to
accept them.
I have tested this locally with:
for p in '-p arti' '--workspace'; do for f in '--no-default-features --features=tokio,native-tls' '--all-features' ''; do nailing-cargo test $p $f; done; done
|
| |
|
|
|
|
| |
We *do* have a thing that works like this.
It's fragile and confusing and that's what I'm about to fix.
|
| |
|
|
|
| |
Bring the exciting tests together, and move some more normal tests out
of the middle.
|
| |
|
|
|
|
|
| |
If all the fields vanish, this generates a warning with
cargo clippy --locked --offline --workspace --all-targets
Fix that.
|
| |
|
|
| |
The breaking changes here do not seem to affect us.
|
| |\
| |
| |
| |
| | |
Remove final "experimental" status from tor-hscrypto and tor-error.
See merge request tpo/core/arti!1291
|