Miloslav Trmač wrote:
> The logical conclusion from this is to move to a language with automatic
> memory management. The "top vulnerability" reports for programs written
> in C/C++ and most other languages so different that starting a new project
> that processes untrusted data in C/C++ is becoming indefensible.
>
> We seem to be stuck with C as the lowest common denominator that can be
> used from any runtime; long-term we _need_ to move away from that, or
> Linux will gain the reputation of least-secure OS around.
>
> Now, what to move to? I currently don't have see any language/runtime I
> could recommend, which is in itself rather frightening.
Well, you don't see any such language/runtime because there isn't any. :-)
Moving from C/C++ to a slower language is neither helpful nor necessary. If
you really want full bound checking, it can be added to C/C++ rather than
moving to a completely different language, and you'd still get the other
benefits of C/C++, in particular, fast native code. It shouldn't be worse
for peformance than switching to another language: After all, the other
languages have to do the bound checking as well!
But the point of the discussion is to find out how much checking is actually
needed for security. In fact, full bound checking is probably not necessary.
I shall also note that vulnerable C++ code is mainly code which uses C-style
data structures for whatever reason (often, interfacing with C-only
libraries). If we all wrote pure Qt code, there would be little to no buffer
overflow vulnerabilities. It's much harder to overflow a QString by accident
than a char *. (The STL is similar there, but IMHO the STL is a horrible
runtime library and should be replaced by QtCore or a subset of it. :-) The
main issues being overuse of templates (e.g., why is std::string a
template?!) and lack of implicit sharing (copy on write). IMHO, C++ is great
as a language, but the STL is hurting its adoption. But still, you also
don't as easily overflow a std::string by accident as a char *.)
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
