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.
Changelog updates are now required in MRs by default. If there is a
match for "\<skip.\?changelog\>" in the commit message, this will be
ignored.
$CI_COMMIT_MESSAGE mangles newlines so it's not possible to require the
string to be on its own line, that means it would also trigger within a
wall of text, which makes it less obvious.
Also, I wasn't able to find a CI variable which has the ref of the
branch the MR is set against, to build a tree-ish than spans over the
whole MR and not just HEAD.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This allows to detect and handle dying streams without getting stuck
forever.
Timeouts are always wrong, though, so we put the burden of choosing the
right values (mostly) on the creator of a stream.
Paths are already patched in the workspace's [patch.crates-io] block.
Not sure why this was added in the first place.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
xmpp-rs normally has the stance to get buggy implementations fixed
rather than dropping checks. In this particular case I think this is not
a good use of resources:
- The disco#info feature var conveys no actual information:
If an implementation replies properly to a disco#info query, it is
already implied that it supports the protocol.
- There are broken server implementations out there.
A lot of them (all recent (>= 0.10 && < 0.13 AFAICT) Prosody IM
instances). At this point in time, xmpp-rs is unable to query
disco#info from MUCs hosted on such prosody versions, except by
workarounds (such as the one removed in this diff).
- XEP-0030 now features a note which reads:
> Note: Some entities are known not to advertise the
> `http://jabber.org/protocol/disco#info` feature within their
> responses, contrary to this specification. Entities receiving
> otherwise valid responses which do not include this feature SHOULD
> infer the support.
The case would be different if there were no (deployed) implementations
which had this bug or if the bug actually had an effect on clients.
Especially the latter is not the case though, as pointed out above.
Hence, I conclude that this check is overly pedantic and the resources
(time, emotional energy of dealing with bugs, punching patches through
to stable distributions, etc. etc.) spent on getting this fixed would
be better invested elsewhere.
In addition, the workaround is extremely ugly and, even in the xmpp-rs
implementation, has no test coverage. Without test coverage of such an
implementation, it is bound to break in funny ways when xmpp-rs changes
the strings of its error messages (which is something one might do even
outside a breaking release).
