| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.37.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
futures-copy
```
We split them in the following categories:
* crates with no changes (no version bumps): None
```
maint/changed_crates -v "arti-v$LAST_VERSION" 2>&1 >/dev/null | grep -i "no change" | grep -v '\(tor\|arti\)-'
```
* crates that only have non-functional changes (bump the patch version,
but not the dependend-on version):
- oneshot-fused-workaround
- slotmap-careful
- test-temp-dir
- fslock-guard
- equix
- caret
- safelog
- retry-error
* crates where functional changes were made, but no APIs were added or broken:
- hashx
- fs-mistrust
- futures-copy
* crates where APIs were broken (bump minor): None
The bumps from this commit were created using this script:
```
PATCH_NF=(
oneshot-fused-workaround
slotmap-careful
test-temp-dir
fslock-guard
equix
caret
safelog
retry-error
)
PATCH="
hashx
fs-mistrust
futures-copy
"
./maint/bump_nodep "${PATCH_NF[@]}"
for crate in $PATCH; do
cargo set-version --bump patch -p $crate;
done
```
|
| | |
|
| |\
| |
| |
| |
| | |
arti: Add rate_limit_at_intro to the example config
See merge request tpo/core/arti!3493
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
hsservice: Clarify what max_concurrent_streams_per_circuit does
See merge request tpo/core/arti!3492
|
| | |
| |
| |
| |
| |
| |
| | |
At first glance, this might seem equivalent to C Tor's
`HiddenServiceMaxStreams` option, but it's actually
`HiddenServiceMaxStreamsCloseCircuit` (Arti doesn't implement the
former).
|
| |/
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |\
| |
| |
| |
| |
| |
| | |
arti/arti-client/tor-hsservice: Support disabling onion services in the config
Closes #2133
See merge request tpo/core/arti!3253
|
| | |
| |
| |
| | |
We don't need to modify semver files for newly added methods.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Combined with the previous commit, this completes my second attempt at
correctly handling the semver files.
tor-hssservice:
I removed the extra bit at the end of the first line explaining the
semantics of the new return type, since the important part is really
just the fact that the return type changed. The semantics are documented
in the methods themselves.
arti-client:
Same as above, but I also removed the `client` module prefix since the
`client` module isn't actually public, so to external crate users the
broken type is directly in the crate root.
Removed old "used in the public API of this crate" line.
Added lines referring to the 2 breaking changes we re-export from
tor-hsservice.
arti-ureq:
Removed old "used in the public API of this crate" line.
Added lines referencing every breaking change in arti-client. This MIGHT
be wrong, but I think this is correct because we re-export arti-client
as a whole.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| | |
Might be too verbose... unsure.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is no longer a hard error anywhere for trying to launch a service
which is disabled in the config. Instead, it always means returning
`Ok(None)`.
The axum and hyper examples were updated again as a consequence.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
The "enabled" config option is back to using a regular `bool`. When
unset, it defaults to true, and the service runs as if it had been set.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As requested in the review, there's a TODO now so we can come back some
day and allow onion services to be started/stopped while the client is
running.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
The "enabled" config option now uses `tor_config::BoolOrAuto`. When
unset (which defaults to "Auto"), the service will run with a warning.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Added the `enabled` field to the config options for hidden services. The
default is `true`. If it is set to `false`, the service won't start. As
of this specific commit, it's a hard error; it'll be checked again at
an earlier stage where it won't be once the feature is ready.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
This has the meta attributes with optional values feature and also
hygiene rework for modules.
The breaking changes don't break arti.
|
| |\ \
| | |
| | |
| | |
| | | |
Bump derive-deftly to 1.4.0
See merge request tpo/core/arti!3448
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This will let us use the new modules feature.
There are no breaking changes to beta features in 1.4.0.
|
| |/ /
| |
| |
| | |
Run maint/add_warning
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
```bash
readarray -t publish < <(cargo metadata --format-version 1 | jq -r '.packages[] | select((.id | startswith("path+file:///")) and (.rust_version != null) and (.publish == null or .publish == true or .publish != [])) | .name')
for package in "${publish[@]}"; do echo "$package:"; cargo set-version --bump minor -p "$package"; done
```
|
| |\ \
| | |
| | |
| | |
| | | |
arti: Mark restricted-discovery as non-experimental
See merge request tpo/core/arti!3384
|
| | |/
| |
| |
| | |
As per the team decision from the 14 Oct Arti sync.
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| | |
tor-hsservice: Replace `libc::EFBIG` with `io::ErrorKind::FileTooLarge`
See merge request tpo/core/arti!3218
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Resolved an MSRV TODO. We used `libc::EFBIG` previously because
`io::ErrorKind::FileTooLarge` was still unstable. It has since
stabilized and entered our MSRV (>= 1.83.0).
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
Unless this is a pun, I'm pretty sure this is supposed to be `EFBIG` and
not `EFBUG`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because we've updated our MSRV, we must bump the minor version for every
package.
This was done as follows:
cargo set-version -p arti 1.6.0
cargo set-version -p oneshot-fused-workaround 0.4.0
cargo set-version -p slotmap-careful 0.4.0
cargo set-version -p test-temp-dir 0.5.0
cargo set-version -p fslock-guard 0.4.0
cargo set-version -p hashx 0.5.0
cargo set-version -p equix 0.4.0
cargo set-version -p caret 0.7.0
cargo set-version -p fs-mistrust 0.12.0
cargo set-version -p safelog 0.6.0
cargo set-version -p retry-error 0.8.0
xargs -I P <<END cargo set-version -p P 0.35.0
tor-basic-utils
tor-error
tor-general-addr
tor-geoip
tor-rtcompat
tor-rtmock
tor-async-utils
tor-config
tor-config-path
tor-rpc-connect
tor-log-ratelim
tor-rpcbase
tor-memquota
tor-units
tor-llcrypto
tor-bytes
tor-protover
tor-checkable
tor-cert
tor-key-forge
tor-hscrypto
tor-socksproto
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-relay-selection
tor-persist
tor-keymgr
tor-chanmgr
tor-ptmgr
tor-dircommon
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-dirserver
tor-hsclient
tor-hsservice
tor-hsrproxy
tor-relay-crypto
arti-client
arti-relay
arti-rpcserver
arti-ureq
arti-rpc-client-core
END
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This behaviour was changed in humantime 2.3.0. Because they made this
breaking change on a minor semver bump, if we want to depend on this
behaviour, we would need to lock to a specific version. I don't think
this is critical, but I am still looking into where exactly this is
used.
|
| | |
| |
| |
| | |
This feature has been removed from nightly, in favor of doc_cfg.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
An `OnionService` represents a not-yet-running service. To launch it,
you have to call `OnionService::launch()`, which consumes the
`OnionService` and returns `RunningOnionService`, so the part of the
docs saying that an `OnionService` "may or may not be running" was
somewhat misleading.
|
| | |
| |
| |
| |
| |
| |
| | |
This adds some extra docs to `RunningOnionService`.
This also removes the TODO about #1228, because that ticket was closed
in !1945.
|
| | |
| |
| |
| | |
In #1247 we decided to stick with the current names.
|
| | |
| |
| |
| | |
Closes #2107
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
various crates: Updated MSRV TODOs for `once_cell` removal
See merge request tpo/core/arti!2953
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Shortened the TODO added in cad6f9054a5ff4d16e953fd4617d3893639deeef in the
style of [this maintainer request] for consistency.
[this maintainer request]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2953#note_3197719
Signed-off-by: hashcatHitman <[email protected]>
|
| | |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Per policy, we bump the minor version of every tor-*, arti-* crate
on each release.
We have updated our MSRV, so we're treating this as a breaking
change for our non-(arti/tor)-prefixed crates too.
|
| |\ \
| | |
| | |
| | |
| | | |
Run "fixup-features" in preparation for release.
See merge request tpo/core/arti!3196
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| | |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an error from nightly. The trouble is that with nightly,
there's a now a [derive macro for From][issue]. That doesn't cause
a conflict when we `use derive_more::From`, but it _does_
cause a conflict when we import `derive_more::From` via
`use internal_prelude::*`.
So as a solution, we just import `derive_more::From` explicitly.
Closes #2124
[issue]: https://github.com/rust-lang/rust/pull/144922
|
| | |
|