Bump deps

[rustworthy]

This change is 

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 67.5%. Comparing base (6ff7d60) to head (54e30bc).

Files with missing lines	Patch %	Lines
src/tls/rustls.rs	0.0%	1 Missing ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
src/tls/native_tls.rs	0.0% <ø> (ø)
src/tls/rustls.rs	0.0% <0.0%> (ø)

... and 1 file with indirect coverage changes

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[rustworthy]

I think we were locked above this patch version, but still it's worth tightening due to potential vulnerability. Yay for deps.rs !

[jonhoo]

In general, vulnerabilities shouldn't be patched in consumers through their Cargo.toml bounds — the lockfile is for this. The manifest (Cargo.toml) is just for declaring bounds on what's possible to build with. We don't want to restrict this to a newer version unnecessarily as it would mean consumers that are locked on an older version for some reason are stuck without a path forward.

[rustworthy]

Hmm I agree that the bounds should be kept as low as possible, especially if the library is not relying on features added in minors and patches of its dependencies. However, a vulnerability fix may (should?) be considered a feature we are relying upon, so I am not sure this is an "unnecessary" bump. It somehow feels not right.

And also can they really get locked on an older version in this case? If they could build their app with 0.4.0 till 0.4.19, they should be able to build with 0.4.20.

[jonhoo]

No, a vulnerability fix is not something we depend on :)

And yes, they can, such as if they use <= or = dependency specifiers.

[rustworthy]

this is technically possible, but I mean logically why would they go with <=0.4.19 or =0.4.19 for example :)

[jonhoo]

I've paged this out already (blame the holiday 😅), but do we have types from either of these in our public API (esp. in trait implementations)? If so, this change will require a major version bump for faktory as well.

[rustworthy]

Our TlsStream derefs to tokio_rustls' stream.

Besides, TlsStream::with_client_config accepts a config struct from rustls. We are using rustls re-exported from tokio_rustls, and a major bump also took place there.

As for rustls-platform-verifier - it's not part of our API.

[rustworthy]

So this probably - and unfortunately - should be a 0.14.0 release candidate.

[rustworthy]

Alternatively, we can postpone these bumps and batch with other libs major versions updates that may come in the next couple of months.

I am now doing #61 and then will take #88. Bot of them are only extending what we currently got.

[jonhoo]

Ah, that's unfortunate. Yeah, I think let's maybe hold off then in case we see other breaking changes coming down the line 👍