Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
Control: block -1 by 1013913 1013915 Quoting plugwash (2022-06-27 03:11:42) > I'll remove the rustls support completely until/unless it can be > re-enabled in a sane form. I took the "unless" as an invitation: Rust crates tokio-rstls and hyper-rustls have now been packaged and are pending NEW approval. Please consider postponing removal of rustls support until that NEW processing is done. Thanks for all your work on this, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
Quoting plugwash (2022-06-27 03:11:42) > > 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. Please do. Bogusly advertising a feature not actually provided is what I find horrific here. With this change alone I find it sensible to lower severity of this bugreport back to "normal" (but that is just a suggestion: you as package maintainer has final say in how you treat bugreports for this package). > 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. Removing features but continue advertise them as offered (through package names containing "+") is what I consider horrific here. It is arguably correct that you didn't change any *code* but you patched Cargo.toml file to remove upstream-declared dependencies, causing builds to succeed that should have failed. > 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. I find it sensible that you choose to skip some features. I am not sure I find it sensible to *redefine* some features to mean something else that upstream, however. If you choose to do that, please consider making such strong deviation *very* clear - e.g. *both* document it in README.Debian and *also* mention it in long description. Let me try clarify my concerns here: I find it problematic generally is that Debian package deviates notably from upstream project without it being explicitly documented. By explicit documentation I don't mean changelog (and certainly not patch files installed next to code) but a README.Debian file. What I then find horrific here is that the vague deviation information hinted in virtual package names is not reliable. Please consider documenting deliberate deviation from upstream in README.Debian, in addition to ensuring that provided package names accurately reflects the features offered by the package. And please reconsider your proposed plan to change features to mean something different from what they are documented upstream to mean - especially when no Debian-specific documentation is offered! Thanks, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
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.
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
Control: severity -1 serious Quoting Peter Michael Green (2022-06-26 23:40:37) > > 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. > 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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
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.
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
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 signature.asc Description: signature
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
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.
Bug#1013869: rust-reqwest: feature rustls-tls has disappeared
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-
