Auditability / Cheating
dbrgn opened this issue · 8 comments
Just a small thought after seeing this project for the first time: The name of this crate implies that the embedded information allows ensuring that no vulnerable dependencies were used. However, if I'm not mistaken, it would be very simple to overwrite this section of the binary, and simply lie about the actual dependencies used, right? (For example, to change versions, or to hide dependencies with "unsuitable licenses".) So while this section makes it easier to find vulnerabilities in your own binaries, it does not make your binary that much more auditable towards third parties that don't trust you.
Maybe a FAQ section in the README ("Can I be sure that the dependency information embedded in the binary is correct?") would make sense. Or maybe "cargo auditable" isn't the best name? (But you've probably thought more about this than I have. Related to #1.)
That's true, but if an attacker can modify your binaries, you have way bigger problems than potentially vulnerable dependencies. Your binary is probably stuffed with malware!
Perhaps I should add an entry to the FAQ?
Hm, that (an attacker modifying my binary) wasn't the case I meant... Instead, I meant a company saying "here are our binaries, you can audit them", who have tampered with their own binaries to make their binaries look safe (or GPL free) while they aren't.
Oh! A company can give you anything if your builds aren't reproducible, the binary is just a black box then.
This again is something that applies not just to audit data but also to the rest of the binary - the much more interesting use is injecting malware!
Reproducible builds are the solution to that, and the format is explicitly designed to avoid disrupting them, but cargo auditable doesn't provide that itself.
Yep, that's my point 🙂
The thing is, if you get the project source, and run cargo audit on it, you can be sure that vulnerable dependencies in it will get caught. If you get a binary, you can't be (unless it's reproducible). That's the point I'm trying to make, the FAQs should probably point it out (in case people assume that "cargo auditable" makes a binary auditable).
The thing is, if you get the project source, and run cargo audit on it, you can be sure that vulnerable dependencies in it will get caught.
That's not really the case because the Cargo.lock can be an almost arbitrary file. Cargo will regenerate it if needed during the build, but a build.rs script can tamper with it and set it to arbitrary values again.
If someone wants to obscure the dependency list, this can be done on the source code level too.
Was the clarification in #109 sufficient? Can I close this, or is there something else to be done here?
I think so, yes! Thank you.