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

Reply via email to