Memory safety problems are the low-hanging fruit of vulnerabilities. A re-write by unskilled programmers will not guarantee the code is safe, because they will introduce many other kinds of vulnerabilities.
Nobody is claiming that Rust prevents all security vulnerabilities. The claim is that memory safety problems are severe enough that a rewrite is justified.
(Incidentally, there are other classes of vulnerabilities that Rust and/or its libraries heavily mitigate, such as deserialization issues along the lines of the Rails YAML bug.)
By removing memory safety bugs, it allows reviewers to focus on the more important sources of vulnerabilities - the things that the compiler can't check. On that front, it is also worth noting that Rust has a much richer type system than C or C++, and can be leveraged to craft domain models that catch many more bugs at compile time.
With all of that said however, I agree with you that it would be foolish to think that a rewrite would not be open to lots of potential vulnerabilities. At the moment might be prudent to continue to use and support the current libraries, but to also support efforts like rust-crypto in order to prepare for the future.
Rust's improvements over C don't just consist of memory safety. It also provides an excellent type system and the ability to statically check for concurrency bugs at a higher level than just memory safety, for instance.
None of these things (except maybe some of the concurrency stuff) are quite new to Rust. It's just that C is such an old language that stuff that other languages have been doing well for decades were not available to systems software.
> Part of what makes Rust awesome is it forces correct...architecture.
If you believe that, and follow it, then you will end up with a lousy architecture. A correct architecture cannot be designed without knowledge of the problem domain.
That's the problem with security too: if you believe the language will keep you safe, and stop thinking about security, your software will be less secure than before. There's plenty of insecure Java code out there.
> That's the problem with security too: if you believe the language will keep you safe, and stop thinking about security, your software will be less secure than before.
And if you use "it won't be perfectly secure under X mitigation strategy" as an excuse to avoid doing X, your software will also be less secure.
