mirrors/arti.git/crates/tor-proto, branch arti-v1.1.12

Followup patchlevel bumps

2024-01-09T13:20:24Z

Followup minor version bumps.

2024-01-09T13:17:45Z

These crates had no changes previously, but they depend on crates that had breaking changes themselves. tor-linkspec tor-hspow

Patchlevel version bumps in preparation for 1.1.12.

2024-01-09T13:11:17Z

This crate doesn't have a meaningful public API, so it just gets a patchlevel bump: arti These crates had nonbreaking changes, and get a patchlevel bump: tor-rtcompat fs-mistrust tor-llcrypto tor-cert

Breaking version bumps in preparation for 1.1.12.

2024-01-09T13:07:43Z

These crates have breaking changes on their own: tor-error tor-netdoc tor-dirmgr tor-keymgr Because of the breaking change in tor-error, and the fact that basically every crate publicly depends on tor-error (by implementing ErrorKind), we need to call this a breaking change on all of the following: tor-config tor-geoip tor-rtmock tor-log-ratelim tor-rpcbase tor-bytes tor-hscrypto tor-socksproto tor-cell tor-proto tor-netdoc tor-netdir tor-persist tor-chanmgr tor-ptmgr tor-guardmgr tor-circmgr tor-dirclient tor-dirmgr tor-keymgr tor-hsclient tor-hsservice tor-hsrproxy arti-client arti-rpcserver arti-config arti-hyper arti-testing

clippy: consequential rustfmt

2024-01-02T15:04:18Z

clippy nightly: For now, locally allow blocks_in_conditions

2024-01-02T15:04:18Z

Filed https://gitlab.torproject.org/tpo/core/arti/-/issues/1176 proposing a final fix.

clippy: Use infallible calls

2024-01-02T13:56:22Z

Resolves clippy complaints about needless fallible conversions.

clippy: Replace many calls to .get(0) with .first()

2024-01-02T13:56:08Z

FTR I don't think agree with clippy on this question, but then I often don't.

Rename {Any}RelayCell to {Any}RelayMsgOuter

2023-12-14T16:56:58Z

This commit is pure renaming, done automatically with rust-analyzer. Comment fixes and other cleanups will be in the subsequent commits. We're doing this renaming because we need a name for the combination of a `RelayMsg` and an `Option` that we use when we have a `RelayMsg` we intend to route to a given stream or circuit internally. Previously we called this a `RelayCell`, but that name was already somewhat inaccurate, and will become _very_ inaccurate with the arrival of prop340, which breaksthe 1:1 relationship between relay cells and relay messages. (If we didn't do this renaming now, we'd soon be making the relationship between `UnparsedRelayCell`and `RelayCell` many-to-many, which would be ridiculous and confusing.) The `RelayMsgOuter` name is a placeholder: We expect that we'll want to rename this type, and may also want to rename `RelayMsg`, and unify our vocabulary in other areas too. But such a renaming will have to wait for a larger discussion affecting the specifications, so that we can use the same vocabulary everywhere.

NtorV3Extension set encoding/decoding: include n_extensions

2023-12-07T15:45:45Z

An encoded set of extensions in the ntorv3 handshake includes a header with the number of extensions. This change adds that header. It also changes `write_many_onto` to take a slice instead of an iterator, since we need to know the number of extensions up-front. In principle we could take a clonable iterator instead and use Iterator::count, but it's probably not worth the extra complexity.