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
```
These crates have had nonfunctional changes only, mostly due to !1271,
or ac90cb7500, or documentation changes: crates that depend on
them do not require a version bump.
```
arti-bench
arti-config
arti-hyper
arti-testing
caret
fs-mistrust
retry-error
tor-async-utils
tor-basic-utils
tor-chanmgr
tor-checkable
tor-congestion
tor-consdiff
tor-events
tor-guardmgr
tor-persist
tor-protover
tor-ptmgr
tor-rtcompat
tor-rtmock
tor-units
```
We need the fix from [82d69902], which first appeared in async-trait
version 1.54. (Technically we only need this fix in tor-hsclient,
but we may as well update our minimal async-trait version everywhere.)
[82d69902]: 82d6990253
Previously, there was a bug in the way that our code used our SOCKS
implementations. If the buffer used for a SOCKS handshake became full
without completing the handshake, then rather than expanding the buffer
or closing the connection, our code would keep trying to read into the
zero-byte slice available in the full buffer forever, in a tight loop.
We're classifying this as a LOW-severity issue, since it is only
exploitable by pluggable transports (which are trusted) and by
local applications with access to the SOCKS port.
Closes#861.
Fixes TROVE-2023-001.
Reported-By: Jakob Lell <jakob AT srlabs DOT de>
I could also have stopped using `::default()` to construct this
(testing-only) object, but I think it makes more sense to turn it
into a non-unit object.
This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
In !948 we renamed a couple of accessor functions, which is a
breaking change in `tor-cell`'s API.
In retrospect, perhaps we should have deprecated the old names and
added the new ones, so we wouldn't have to break the API. (This is
the only API break AFAICT since 1.1.0.)
These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes#748.