• 2 Posts
  • 524 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle



  • You are confusing cargo and crates.io.

    Cargo is the program doing all the downloading of dependencies, crates.io is the official registry (but there are ways to host your own for private crates, e.g. kellnr), Rust is just the compiler and does not do any downloading of anything. For completeness sake, rustup is the program you can use to install cargo, rust and some other tooling and data files.






  • That seems based on the same misconception as the whole “fighting the compiler” view on Rust, namely that other languages are better because they let you get away with not thinking through the problems in your code up front. I am not surprised that this view is common in the C world which is pretty far on the end of the spectrum that believes that they are a “sufficiently disciplined programmer” (as opposed to the end of the spectrum that advocates for static checks to avoid human mistakes).

    The problem you mention is fundamentally no different from e.g. changing some C internals in the subsystem you know well and that leads to breakage in the code in some other C subsystem you don’t know at all. The only real difference is that in C that code will break silently more likely than not, without some compiler telling you about it. The fact that the bit you know well/don’t know well is the language instead of some domain knowledge about the code is really not that special in practical terms.






  • I would say this very issue is at the core of the current CVE discussions that leads more and more projects to become their own CNAs.

    Security people and corporate downstream consumers of security feeds want to invest the minimum of effort while pushing as much of the evaluation what is and isn’t a vulnerability on the authors of library authors as possible. However, this does not work. A vulnerability can only ever truly be evaluated by investing significant amounts of effort in the abstract way that is required to do it in an upstream project. On the other hand, at point of use it is often trivial to discard the possibility of an exploit because the potentially vulnerable code is not even used by the project using the library that contains the code.




  • No, I actually meant it as in the traditional meaning of literally. As in

    [lints.clippy]
    unwrap_used = "warn"
    expect_used = "warn"
    

    along with a pre-commit hook that does

    cargo clippy -D warnings

    (deny warnings).

    There are always better ways to write an unwrap, usually via pattern matching and handling the error cases properly, at the very least logging them.