| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since config-rs has a bug breaking its support for nested arrays
(see discussion at !1640), we're temporarily changing the format
to a single string with a "=>" in the middle.
I've opened #1058 to put things back as they were once config-rs is
fixed.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
The problem here is that, for some reason, the proxy_rule
configuration doesn't actually work. I suspect a bug in
Flatten, since the same configuration works fine if you pass
it to the hsrproxy config directly.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
The old name was a copy-paste error.
|
| | |
| |
| |
| | |
This lets us write `[onion_services.allium_cepa]`.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
There are no tests for parsing it yet.
|
| | |
| |
| |
| |
| | |
These don't yet attach to the rest of the ArtiConfig, or actually
launch any onion services, but they're a start.
|
| | |
| |
| |
| | |
(The only change in these crates is that their dependencies changed.)
|
| |/ |
|
| |
|
|
| |
I have no idea why these became necessary.
|
| |\
| |
| |
| |
| | |
Version bumps in preparation for today's release
See merge request tpo/core/arti!1570
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are:
```
hashx
equix
tor-async-utils
tor-error
tor-config
tor-rtmock
tor-llcrypto
tor-bytes
tor-hscrypto
tor-hspow
tor-cert
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-netdir
tor-chanmgr
tor-guardmgr
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
arti-client
arti
```
|
| |/
|
|
|
| |
There's a complaint (seen in a CI build log) about over-eager iterator
item cloning. This is a perf complaint and not very relevant in tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Previously we were using backtrace 0.3.39, which has a [bug] that causes
it to segault in some circumstances. I experienced this bug while trying
to fix the minimal-versions build in !1508.
[bug]: https://github.com/rust-lang/backtrace-rs/issues/267
|
| |
|
|
|
|
|
|
|
|
| |
This will allow us to proceed if
* the default config file locations can't be established
(eg due to failure of the `directories` crate), but
* configuration files are explicitly specified,
so the defaults wouldn't be used
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Improves the error mesage in #989 somewhat.
Before:
target/debug/arti: error: Can't construct project directories to resolve a path element
After:
target/debug/arti: error: identify default config file locations: Can't construct project directories to resolve a path element
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | | |
|