First of all, the proliferation of header-only libraries that people vendor into their Cpp projects has the same attack surface. Additionally, there is less tooling to help you track vulnerabilities in Cpp dependencies and upgrade when fixes come out. If you do rely on external cpp deps, then you must have a code review process before those deps are whitelisted for use.
Now, you can extend this code review process to rust crates.
Run a security review of a crate after which that crate is pushed to an internal registry. Every external crate upgrade can go through the same security review process until which point developers will build with the old version present in the internal registry.
In the context of a large enough organisation, an increasing number of crates will become internal, thus solving the trust/responsibility issues.
by no means, do i suggest that crates is unhackable. That's why I want to raise awareness of already existing infrastructure and procedures to vet code before including in your systems.
Safety
Before we get to ownership and some thread-safety, how do you explain the fact that integer addition and number conversion are safe operations in Rust, which throw/panic when they fail instead of the default Cpp behaviour, which _silently_ corrupts data?
The C++ article did not use any header-only libraries, though, it just used the standard library, unlike the post about Rust. And Rust's behavior on overflow is "safe" for a certain definition of safe–in release builds by default it will wrap, which is often undesirable.
I assumed "enormous attack surface" was referring to real systems, not toy examples. AFAIK, even C++ needs more than the std library to solve business problems in the domains I am familiar with. There are many ways to manage dependencies including vendoring in header-only libraries, where my point about the lack of tooling and clunky UX still stands.
I just want to use tools that help me get stuff done. C++ has had a 30-year head start, why can they not see the overall value-add of a default build and test tool and a format for package declaration and management.
I think most C++ developers do see the value of something like Cargo…but it must also be considered that making it easy to bring in dependencies does not also mean the standard library can be poor and you can farm everything out to third parties.
C++ does not have a standard checked arithmetic operation, so I'll concede with you there. It really should, although most people just use the fairly widespread compiler builtins that behave similarly. (That being said, having it not be the default means that people who really need it won't use it, which is the same situation that Rust is in.)
First of all, the proliferation of header-only libraries that people vendor into their Cpp projects has the same attack surface. Additionally, there is less tooling to help you track vulnerabilities in Cpp dependencies and upgrade when fixes come out. If you do rely on external cpp deps, then you must have a code review process before those deps are whitelisted for use.
Now, you can extend this code review process to rust crates.
Run a security review of a crate after which that crate is pushed to an internal registry. Every external crate upgrade can go through the same security review process until which point developers will build with the old version present in the internal registry.
In the context of a large enough organisation, an increasing number of crates will become internal, thus solving the trust/responsibility issues.
by no means, do i suggest that crates is unhackable. That's why I want to raise awareness of already existing infrastructure and procedures to vet code before including in your systems.
Safety
Before we get to ownership and some thread-safety, how do you explain the fact that integer addition and number conversion are safe operations in Rust, which throw/panic when they fail instead of the default Cpp behaviour, which _silently_ corrupts data?