[Pkg-rust-maintainers] Bug#969839: rust-failure: Should rust-failure be removed from unstable?

[peter green]

reassign 973298 rust-failure
retitle 973298 rust-failure: Should rust-failure be removed from unstable?
thanks

> As there was no objection (although admittely 2 weeks might be short),
> but the upstream is officially end-of-life. So just reassigned the
> bug to ftp.d.o for removal.

I've just spotted this bug report.

The reverse dependency checking in dak rm does not work
for rust packages due to the way they use virtual packages.

To check for references to packages from rust-failure in other packages I used
zcat /srv/ftp.debian.org/mirror/dists/sid/main/binary-amd64/Packages.gz | grep-dctrl rust-failure -sPackage
On mirror.ftp-master.debian.org

and

zcat /srv/ftp.debian.org/mirror/dists/sid/main/binary-amd64/Packages.gz | grep-dctrl rust-failure -sPackage

then manually dug into the results the results, remoed false grouped things by source
package followed the reverse dependency tree etc.

   rust-assert-cli: hard dependency, no apparent reverse depends, package not in testing
   rust-cargo-lichking: package is already rc buggy and not in testing, no apperent reverse depends
   rust-cpal: hard dependency
     qwertone: Package is already rc buggy and not in testing.
   rust-mdl: hard dependency, no apparent reverse depends.
   rust-rspotify: hard dependency
     rust-spotify-tui: package not in testing
   rust-spotify-tui: covered above
   rust-html2pango: hard dependency, no apparent reverse depends.
   rust-include-dir-impl: hard dependency, no apparent reverse depends.
   rust-mdl: hard dependency, no apparent reverse depends.
   rust-sloppy-rfc4880: hard dependency, no apparent reverse depends.
   rust-sniffglue: hard dependency, package not in testing, no apparent reverse depends, libary and application package
   rust-tokio-process: hard dependency
     rust-jobserver: autopkgtest dependecy only, can probablly be ignored, rdeps not investigated
   rust-trust-dns-proto: hard dependency, no apparent rdeps
   rust-vergen: hard dependency, no apparent rdeps
   rust-tui: autopkgtest dependecy only, can probablly be ignored, not in testing, rdeps not investigated
   rust-which: not needed by the "no features" configuration, but needed for the "failure" "use_failure" and "default" featuresets, no apparent reverse depends for effected feature but important rdepends for other features.

In addition to the reverse dependencies there are also embedded copies of the failure crate in firefox-esr
and thunderbird.

I think that is enough of a pile of rdeps that this package should not be removed at this time.

I don't personally think RUSTSEC-2019-0036 deserves a rc severity. As I understand it safe rust is not a sandbox,
it's supposed to be an environment that is protected against memory safety errors but there is still plenty of scope
for safe rust to do evil and you should not be running "safe rust" code you do not trust (at least not without
additional sandboing measures but probably not even then).

RUSTSEC-2019-0036 is about something that was exposed to safe rust that should not have been. That isn't nice,
but it's only of practical impact if the incorrectly exposed functionality is actually used somewhere.
I searched for __private_get_type_id__ and the only references I can find are within the "failure" crate
(both the rust-failure package and the embdedded copies of the crate in firefox/thunderbird).