Bug#1013869: rust-reqwest: feature rustls-tls has disappeared

[Jonas Smedegaard]

Source: rust-reqwest
Version: 0.9.19-5
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

t-reqwest is finally installable. Yay!

Unfortunately, the feature rustls-tls has disappeared.

Please re-enable support for feature rustls-tls, needed by packages I am
preparing for Debian.

- Jonas

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK4GJ4ACgkQLHwxRsGg
ASHHkw/8CJpyEa5k2dowRHlsrVG+u1KfUJZFmCz/k49xrzaDdog8UfdNOw7YQTet
NPpgT+EV48I2eKebYAGv1kY1vX+vxKD8CmFhn0TAAlRr8e6LB7/pBeiefsAKfOtT
O+UZaO0uMivQuRwyfzx4EzHVRg5sHRDEdKfVVCKDEeyOgz6lv0Y9vmTTKSETY/zB
BBTxR0Ow6196SqTk+KH49wyZ2cKIa7nqQoieIpiJ+5RfodIElow/RcgS6wh443md
0zU3RR6BEPA5fVRQ7dRs8J9RNMbsTC5F+DxlvBB+FHTrPrKDCXw4CHrRRwI14mvc
f69g/81qGsRM4n0xIZNvG3A49bmzaS6b3xBHUvcCjo2CG4FjbAKeA1mQSg1algSO
ycE1E4YQTiw6rBNXiln2/7ErRrD7ISg98LEKV2uJX75GYYleaMapO+PUHijsbC5P
BW9sf4yq6mUBfgld8K7hVOvvFhP1eb+1nTK8GvYge5rbqC8QZ1ODmZKgjEFsCYX1
1f+SIKmVhaHDCrKXFO9eU9xv9XGblZjpuMV4cs717mm4iK3X2OHBunXBTkGnRrY+
Fgfae9senYcQ8hYhQ63WkViArB1KCqqAvkZW8Faq4eV8n3V++jsyRXnS95vn/ary
puzKnVBpJLcZGyTnay2qghPbkebhV6q7U7eGCbZQt0MFpWoqE/g=
=alj6
-----END PGP SIGNATURE-----

[Peter Michael Green]

reopen 1013869
thanks.

the (to me, at least) relatively cryptic changelog entry

Sorry if the changelog wasn't clear. I was building a stack of patches
with the expectation that some of them would be removed later.

reqwest upstream offers several options for tls.

native-tls/default-tls (enabled by default): this uses the rust-native-tls crates which on Linux systems means it uses openssl
rustls-tls-manual-roots: rustls with the application expected to supply root certificates.
rustls-tls-webpki-roots/rustls-tls: rustls with roots from the webpki-roots crate
rustls-rls-native-roots: rustls with roots from the operating system certificate store.

Presently only the default/native tls option is supported by the Debian package,

To enable rustls support with native or manual roots two crates which are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls Alexander Kjäll prepared a package, which I have just sponsored into NEW. I don't see any evidence that anyone is working on hyper-rustls however.

To enable rustls support with webpki roots it would additionally be necessary to re-introduce the rust-webpki-roots package. I personally would be very skeptical about reintroducing it though, having root certificates hardcoded into application binaries is just not something packages in Debian should be doing without an extremely good reason.

[Jonas Smedegaard]

Quoting Peter Michael Green (2022-06-26 19:01:04)

> To enable rustls support with native or manual roots two crates which
> are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls
> Alexander Kjäll prepared a package, which I have just sponsored into
> NEW. I don't see any evidence that anyone is working on hyper-rustls
> however.

Not sure what you are saying above. Feature "rustls-native-certs" *is*
currently offered. Are you saying that that is broken until either of
tokio-rustls or hyper-rustls gets into Debian?!?

> To enable rustls support with webpki roots it would additionally be
> necessary to re-introduce the rust-webpki-roots package. I personally
> would be very skeptical about reintroducing it though, having root
> certificates hardcoded into application binaries is just not something
> packages in Debian should be doing without an extremely good reason.

I agree - which was the reason I closed this bugreport, and instead
patched the projct I am preparing to use feature "rustls-native-certs".

Fine that you reopen this bugreport if _you_ want to continue tracking
this, but since I no longer have a need for reqwest feature "rustls-tls"
please then adopt this bugreport - e.g. with `bts owner 1013869 !`.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

[Peter Michael Green]

On 26/06/2022 18:40, Jonas Smedegaard wrote:
> Quoting Peter Michael Green (2022-06-26 19:01:04)
>> To enable rustls support with native or manual roots two crates which
>> are not in Debian, tokio-rustls and hyper-rustls. For tokio-rustls
>> Alexander Kjäll prepared a package, which I have just sponsored into
>> NEW. I don't see any evidence that anyone is working on hyper-rustls
>> however.
> Not sure what you are saying above. Feature "rustls-native-certs" *is*
> currently offered. Are you saying that that is broken until either of
> tokio-rustls or hyper-rustls gets into Debian?!?

In rust every optional dependency is automatically a "feature"
even if it is not actually intended to be used as one by downstream
crates.

I could have stripped out the rustls stuff completely, in retrospect
it would have been less confusing to do it that way, rather than
what I did which was going through the unsatisfiable optional
dependencies one by one patching out the optional depedency
and the features that depend on it. This left some "orphan" optional
dependencies which are satisfiable but aren't much use right now.

Depending on the "rustls-native-certs" feature is not a route to
functioning tls support.

[Jonas Smedegaard]

Control: severity -1 serious

Quoting Peter Michael Green (2022-06-26 23:40:37)

Thanks for clarifying.

I consider it a *horrific* bug that an interface is explicitly
advertised as available, linking against it succeeds, yet it is
non-functional.

In my opinion this renders the whole package unsuitable for release, and
I hereby flag this bugreport as such.

Please as a minimum ensure that broken or missing features are *not*
advertised by the package.

[plugwash]

On 27/06/2022 01:15, Jonas Smedegaard wrote:
> Thanks for clarifying.
>
> I consider it a *horrific* bug that an interface is explicitly
> advertised as available, linking against it succeeds, yet it is
> non-functional.
>
> In my opinion this renders the whole package unsuitable for release, and
> I hereby flag this bugreport as such.
>
> Please as a minimum ensure that broken or missing features are *not*
> advertised by the package.

I'll remove the rustls support completely until/unless it can be
re-enabled in a sane form.

but lets be clear not every "feature" that exists in a rust crate
actually provides useful functionality. The "feature"
"rustls-native-certs" was never advertised as providing any particular
functionality. At this point I have only removed features, I have not
changed the functionality of any existing features. Depending on the
"feature" "rustls-native-certs" would be just as useless with the
unmodified upstream source as it would be with my patched version.

Assuming tokio-rustls and hyper-rustls are packaged, I do intend to
switch the "rustls-tls" feature from being an alias for
"rustls-tls-webpki-roots" to being an alias for
"rustls-tls-native-roots" in line with what I believe is appropriate for
Debian. Indeed I already have a patch in the package doing that, but the
feature is currently removed completely by a patch later in the series.