> The memory safe subset of C++ is also an option.
This does not actually exist, as far as I'm aware. There are certain things people propose doing in C++ that eliminate a small number of issues, but I haven't seen anyone clearly define and propose a subset of C++ that is reasonably described as memory safe. Even if such a subset existed, you would still need some way to statically enforce that people only use that.
Even just writing the parsers in Lua should be a safer choice than writing it in C, but I think now is as good of a time as any to start writing critical code paths in Rust. If the Linux kernel is beginning to allow Rust for kernel modules, then it is high time that OpenSSL looked more seriously at Rust too
As others have pointed out, parser generators could be a useful intermediate option for some of this.
You can write memory safe C++ easier than memory safe C. The problem of statically verifying it the C++ is actually memory safe because of the numerous ways to write unsafe code in C++ is a different goalpost.
My point is that there isn't a compelling reason to write new code in C for something where safety is critical.
> What to do with leaks out of temporaries? : p = (s1 + s2).c_str();
> pointer/iterator invalidation leading to dangling pointers
I feel like those are relatively common memory safety pitfalls, not obscure corner cases. The Core Guidelines have been in the works for about 7 years, I think? It's not clear if/when these will ever be addressed if they haven't been addressed by now.
There are other things mentioned in the list that look suspicious, but they're less clear. So, unless I'm misreading this, then I stand behind my original assertion that there is no safe subset of C++, but the Core Guidelines are certainly better than nothing... assuming they're actually used/enforced in real world applications. Other people are welcome to have their own opinions.
No, it's not. There is no set of guidelines that exists today that creates a memory safe subset of C++. If you claim to have one, and it have a way of verifying that a program satisfies those guidelines, I'll find you a program that has unsafe behavior.
That is your opinion, many folks at ISO C++ see it differently.
Hence why the ongoing efforts to improve static analysis tooling in regards to mechanical enforcement of C++ Core Guidelines across all major C++ compilers, IDEs and commercial static analysers.
It is perfect? Don't let perfect be the enemy of good.
In any case, anyone that cares about secure code shouldn't be touching any language that is copy-paste compatible with C, unless they can't avoid it.
I think you fundamentally misunderstand what memory safety means. "Kinda sorta better" is not memory safety. It's when you can pick out a safe subset of the language and guarantee, barring errors in the language implementation itself, that certain kinds of errors are not possible. C++ cannot do this today and implementations I have seen for C have required semi-invasive changes to the language itself.
I think you fundamentally misunderstand how static analysers and check-in hooks can be used to force everyone to play by the rules, assuming management plays ball with SecDevOps best practices.
As for the rest, I was quite clear where I stand on my last sentence.
I don't get it. You responded to a post that talks about a memory safe subset of C++ by mentioning the Core Guidelines. You are aware of what memory safety is and how this doesn't actually solve that problem (I know you are, you've been around here long enough). Then why bring it up? The answer to "is there a memory safe subset of C++" is "no". The answer to "should you write security critical software in C++" is "generally no because there is no memory safe subset of C++". The Core Guidelines is a good way to not run into the trivial pitfalls but it's not an answer. Why are you presenting it like one?
This does not actually exist, as far as I'm aware. There are certain things people propose doing in C++ that eliminate a small number of issues, but I haven't seen anyone clearly define and propose a subset of C++ that is reasonably described as memory safe. Even if such a subset existed, you would still need some way to statically enforce that people only use that.
Even just writing the parsers in Lua should be a safer choice than writing it in C, but I think now is as good of a time as any to start writing critical code paths in Rust. If the Linux kernel is beginning to allow Rust for kernel modules, then it is high time that OpenSSL looked more seriously at Rust too
As others have pointed out, parser generators could be a useful intermediate option for some of this.