From the prosody@ room:
- 0114 doesn't mention the removal of @version on the stream, and it
refers to 3920 which has it as a MUST.
- 0114 streams have historically never used @version="1.0"
- @version="1.0" implies stream features which 0114 doesn't have.
- There was a proposal years ago to fix this but a new XEP was preferred
(0225).
The change here uses a compile-time check, and may have to change when
support for 0225 arrives if it's still gated behind the "component"
feature (even though it may be weird to have both under the same
feature). We'll see when we get there.
Signed-off-by: pep <pep@bouah.net>
This provides a clear and consistent interface for selecting TLS-related
features on both (xmpp and tokio-xmpp) crates. All feature checks have
been revamped. All working combinations have been tested (including a
connectivity test + --all-features docs build) using:
```
set -xeuo pipefail
features=(aws_lc_rs ring ktls,aws_lc_rs ktls,ring aws_lc_rs,ring aws_lc_rs,ring,ktls native-tls rustls-any-backend)
export RUSTFLAGS=" -D warnings"
cargo test --no-default-features
cargo test
for feature in ${features[@]}; do
echo ">>> BUILDING with $feature" 2>&1
# Running code or building examples cannot succeed with rustls-any-backend.
features="starttls,$feature"
if [ "$feature" != 'rustls-any-backend' ]; then
if ! cargo test --no-default-features --features="$features"; then
echo ">>> BUILD FAILED for tls feature set: $features" >&2
exit 1
fi
set +e
timeout -sINT -p -k 2 3 cargo run --no-default-features --features="$features" --example keep_connection -- test@hub.sotecware.net "$(pass xmpp/test@hub.sotecware.net)"
status="$?"
set -e
if [ $status -ne 0 ]; then
echo ">>> keep_connection did not shut down cleanly! (status: $status)" >&2
exit 1
fi
else
if ! cargo build --no-default-features --features="$feature"; then
echo ">>> BUILD FAILED for tls feature set: $features" >&2
exit 1
fi
fi
done
RUSTDOCFLAGS="--cfg docsrs" RUSTFLAGS="--cfg xmpprs_doc_build" cargo +nightly doc -Zrustdoc-map --all-features
```
For this, we had to:
- Make the choice(s) of backend explicit in tokio-xmpp features
- Avoid picking a backend through transitive dependencies in xmpp
(reqwest->hyper->rustls).
In addition, we choose the default rustls backend by default and adapt
the examples so that they can cope with either situation.
The user may have to call some global rustls functions depending on the
exact feature set of rustls enabled. Hence, we have to expose it.
Concretely, if the user somehow ends up with more than one rustls
backend, they have to configure one of the backends as default backend
at startup.
insecure-tcp requires the io-util feature of tokio, so let’s enable it
there.
Fixes this error:
5 | use tokio::{io::BufStream, net::TcpStream};
| ^^^^^^^^^^^^^ no `BufStream` in `io`
