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).