8 ms·
If you only need what is in the c std library the number of rust crates you use will be tiny and all from authors within the foundation. The hash gets stored in
by galangalalgol 2y ago
If you only need what is in the c std library the number of rust crates you use will be tiny and all from authors within the foundation. The hash gets stored in your repo, so any rebuilds where a dependency repo got compromised and tried to modify an existing version will fail. If you are using a c library that isn't std, then you will probably pull in 10x to 20x the number of dependencies in rust, but not substantially more authors. The risk is real, but if you treat it like c and minimize your dependencies it isn't any riskier, probably less. If you get tempted and grab everything and the kitchen sink you can still be reasonably safe by using the oldest version of crates you can compile with that don't have any cve. That is made easier with crates like cargo deny and cargo audit.
All that said, I would love a language that had the same guarantees and performance without the complexity, but I don't see how that could work. There is definitely extra stuff in rust but the core capabilities come from the type system. Getting the same safety any other way would probably require a purely functional language which has performance costs in any implementation I am aware of along with a runtime being necessary. If you can afford that, then we don't need a new c, we have those languages.
- uecker 2y agoI believe the practical difference to 100% memory safety that Rust offers in theory, or the 99% memory safety you get in practice when using unsafe, compared to the 98% memory safety you can get today when writing decent modern C using abstractions such as string type and modern tooling is pretty irrelevant compared to all the other issues. Yes, the numbers are totally made up, but nothing I have seen so far convinces me that the reality is a lot different. Of course, there is a lot of old crappy legacy C code, and there will even be a lot of new crappy C code, but there will also be pretty bad Rust code. Now, if you like Rust, more power to you, I have no issue with people prefering Rust. But I think arguments for having to write in Rust for security reasons are mostly based on a series of fallacious arguments.
- IshKebab 2y ago> Yes, the numbers are totally made up Indeed. > but nothing I have seen so far convinces me that the reality is a lot different https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities https://www.memorysafety.org/docs/memory-safety/#how-common-... This is very well studied. > Of course, there is a lot of old crappy legacy C code Ahh... you don't make mistakes. I see.
- uecker 2y agoI don't think anything "studied" there addresses my point.
- steveklabnik 2y ago> Yes, the numbers are totally made up, but nothing I have seen so far convinces me that the reality is a lot different. This is really what a lot of all of this comes down to, Herb and the committee feel like you do, others feel that the numbers won't be that good. We'll see in time!
- IshKebab 2y ago> We'll see in time! If by "in time" you mean last year then yes... https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...
- steveklabnik 2y agoI meant the opposite, the claim by sutter et al is that new C++ code that uses these new techniques will show the same results as this study shows for MSLs.
- IshKebab 2y agoOh I see. Yeah I agree. That's going to be a long time!
- steveklabnik 2y agoTo put an even finer point on it, crates.io releases are immutable, and so the only scenario in which you are even in a place where someone could try and modify a release is if you're depending on a git repo directly.