RUSTSEC-2020-0011: make obsolete (closes #275)

[Manishearth]

See discussion in #275

Fundamentally, this is a bug in cargo-geiger. If cargo-geiger users care about this, they should either retool cargo-geiger to handle this, or have the tool notice this crate itself and handle it specially. Unsafe is not a security issue, it is a security smell, and this database is about security issues.

I also strongly agree with @CAD97's comment here, we should stick to objective advisories. There are other tools for dealing with crate trust. I feel like the inclusion of this crate in this database feels like a lowering of standards, and for a security database to work it needs to have people to trust its objectivity.

I think it is a very bad idea to get in the business of deciding what crates are good and bad.

[yaahc]

Is it supposed to say obsolute with a u

[Manishearth]

... maybe

[alex]

Several folks have argued that vulnerabilities should be objective, but I think that's overstating how objective all the existing vulnerabilities are. We don't make any assessment of exploitability before merging things. Lots of folks argue that 1-byte heap buffer overflow reads shouldn't be treated as vulnerabilities, or uninitialized memory reads ("garbage in, garbage out"). But we treat those as vulnerabilities here!

…

On Sat, Apr 25, 2020 at 11:48 PM Manish Goregaokar ***@***.***> wrote: ... maybe — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBHXDB76TIB5B6SAUZDROOVJHANCNFSM4MRAXOXA> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[Manishearth]

In Rust there are two kinds of vulnerabilities around unsafe: "this API has parameter choices that are undefined behavior/bad memory access" and "this API can be used in such a way in downstream code that leads to it invoking undefined behavior or bad memory access" (in C and C++ the latter is basically always true, vulnerabilities are more of the former kind). Essentially, the difference between "an attacker can exploit this" and "downstream can exploit (or accidentally trip) this". withoutboats goes into some detail on this here

It's already unfortunate we conflate the two. The first is a matter of "everyone should patch asap", the second is a matter of "downstream code should be audited for problematic use, and should trigger the first kind of vuln on those" (though ideally everyone patches anyway). Ideally as a community we have ways to talk about these differently because the implications, severities, and social dynamics are different. We don't, but that's not the problem at hand.

Plutonium is not in either category, it is in the category of "this API can be used in such a way that it can create APIs that can be used in such a way that downstream might have UB". This is another level of meta, and to me it's very subjective if that class should be considered as a class of vulnerabilities. It's only being considered as a member of the "downstream can exploit this" class because it's actually "downstream can exploit this to circumvent cargo-geiger", which is a very different statement and not indicative of a vulnerability.

You're right that "Lots of folks argue that 1-byte heap buffer overflow reads shouldn't be treated as vulnerabilities, .... But we treat those as vulnerabilities here!" . Except that's the point! We have an objective metric here; anything falling in the two categories I listed is a vuln. There's no arguing about that because we have this objective metric. Plutonium, to me, does not clear this metric, it seems to have been added via ad-hoc justification.

[tarcieri]

In the interest of putting this whole incident behind us, I'm going to go ahead and merge this.

I still think there's a discussion to be had around policy for these sorts of vulnerabilities, but I think we can suss that out at such a time another one has been opened.

[anderejd]

Fundamentally, this is a bug in cargo-geiger. If cargo-geiger users care about this, they should either retool cargo-geiger to handle this, or have the tool notice this crate itself and handle it specially. Unsafe is not a security issue, it is a security smell, and this database is about security issues.

This has nothing to do with cargo-geiger. It's about the intent to lie to the users higher up in the dependency graph! I don't believe this. Is this the official Mozilla stance?

[tarcieri]

@anderejd see the ongoing discussion on #275

[CAD97]

@anderejd RustSec is completely unaffiliated with the Rust language project.

[tarcieri]

Note: RustSec is part of the Rust Secure Code WG

[Manishearth]

I don't see what Mozilla has to do with it, my participation in the Rust project is not as a representative of Mozilla. My position here is my personal position.

[anderejd]

My position here is my personal position.

That's good to know thanks for the clarification. When a user account with the mozilla and rustlang org steps in and demands changes in a Rust context the voice of that user does carry extra weight regardless of if that is the intention or not.