mirrors/arti.git/crates/tor-netdir, branch arti-v1.4.4mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.42025-06-05T10:33:57Zrelease: Bump all tor-/arti- crates to 0.31.0.2025-06-05T10:33:57ZAlexander Hansen Færøyahf@torproject.org2025-06-05T10:33:57Zurn:sha1:95180f80d7ab574a95368f3bca1e7b78555d479a
This was done using:
for crate in $(./maint/list_crates | grep -P '^tor-|^arti-'); do
cargo set-version -p $crate 0.31.0
done
./maint/cargo_sort: Run cargo-sort on the entire workspace.2025-05-27T13:32:26ZGabriela Moldovangabi@torproject.org2025-05-23T13:54:02Zurn:sha1:03885fdbf4ea19b9215e05cc557372758359f44d
The [latest version] of `cargo-sort` is more opinionated than the
previous one, and is now causing the `rust-checks` job to fail on
`main`.
This commit applies the fixes needed to satisfy the new `cargo-sort`
rules. These changes were generated by running `cargo sort --workspace`
several times, until `cargo sort --check --workspace` finally succeeded
(it couldn't fix all the errors in one go, for some reason).
I have omitted the changes `cargo-sort` made to the top-level
`Cargo.toml`, to preserve the topological ordering of the workspace
members.
Closes #2014
[latest version]: https://github.com/DevinR528/cargo-sort/blob/f066ae80e5e6f5c1d8f0e2b8099461dcb97d9656/changelog.md#200
netdir, relay-selection: require Fast and Stable for rendpoints.2025-05-20T19:22:08ZNick Mathewsonnickm@torproject.org2025-05-20T13:07:29Zurn:sha1:c51745d1d0cdfb3363d8b505c7c749f70276ab57
Since we don't know what kind of traffic we'll use a rendezvous
point for, we don't want to use it if it isn't "Fast" (reasonably
high bw) and "Stable" (unlikely to crash soon).
hs: Prevent a client from using a `MiddleOnly` relay for onion services2025-05-20T19:22:08ZNeel Chauhanneel@neelc.org2025-04-03T00:38:04Zurn:sha1:94baab29f330fd17269e6b44958896b3f9ca794a
> The actual impact of this patch is to prevent usage of MiddleOnly
> relays as Introduction Points. The Rendezvous Point logic isn't
> hooked up yet - nick
netdir: fix warning about an opportunity to use saturating_sub2025-05-16T01:31:14ZNick Mathewsonnickm@torproject.org2025-05-16T01:31:14Zurn:sha1:4aa98c7e3c462a4c83e303c9b52c8bebc4e44c9dAll crates: bump rust-version to 1.83.2025-05-13T18:46:28ZNick Mathewsonnickm@torproject.org2025-05-13T18:46:28Zurn:sha1:88e911acd4bb70bf1da0fc71d77b51cb6abde478release: Bump all unstable tor/arti crates to 0.30.02025-05-01T16:22:28ZWesley Aptekar-Casselsme@wesleyac.com2025-05-01T15:55:57Zurn:sha1:770aaa9648d42835b2c6b3b29f4051d287ddba88
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.30.0
done
```
tor-netdir: Warn on one more case of insufficient items2025-04-29T22:52:39ZNick Mathewsonnickm@torproject.org2025-04-29T19:25:23Zurn:sha1:ad2560e2efb80cc44b09d15eff0c761857142ac7
Now that choose_multiple_weighted can once more return
fewer items than requested, we should warn when it does so,
to be consistent with our other cases of warning about #1907.
tor-netdir: test for rand 0.9.1 behavior instead of 0.9.02025-04-29T22:52:34ZNick Mathewsonnickm@torproject.org2025-04-29T19:20:59Zurn:sha1:3b0cef1642702641acb55046792af8aae5a26b8f
Rand 0.9.1 reverted the changes that caused #1903,
in https://github.com/rust-random/rand/pull/1623.
This broke our test that made sure that rand wasn't going to change
their behavior _again_ :)
Update rand requirement to 0.9.12025-04-29T22:52:26ZNick Mathewsonnickm@torproject.org2025-04-29T19:04:27Zurn:sha1:fc0810c1091b2ec606111ae94e726cf5f7b10b38
(This is going to be a _requirement_,
since rand 0.9.1 has a behavioral change from 0.9.0)