Meaningless statement - 'fault' in these discussions is impossible to objectively attribute. Is every vulnerability the fault of the developer writing the code, or the tool that facilitated the code? Some would argue the former, some the latter.
The end result is the same - using these tools you can produce vulnerabilities, and your users get exploited all the same. So is fault really important?
> Writing a parser in a memory-safe language does nothing for it's correctness, as memory safety is not the only security problem. One should use a domain specific language, as simplicity is very important for safety.
You have two statements here - one is that memory safety is no the end of safety, one is that simplicity is important to safety beyond memory safety.
The first feels... weak. No kidding - security encompasses more than memory safety. But eliminating memory safety issues limits what you have to worry about.
As for simplicity leading to security, this isn't a supported argument. But as for encoding semantic security issues into your program (security issues outside of memory safety), I would argue a strong type system is the right way to go here, something Rust certainly provides.
> edit: Rust is the new systemd, full of fanboys pushing it forcefully on others (or, as they say, "gently nudging"). I have not much to say against rust itself (except that it is not for "systems programming"), but the fanboys are idiots.
blah blah blah, literally just vapor at this point, not worth addressing.
>Ragel is still better then a generic programming language for writing parsers, by a long shot.
>That said, THIS ARTICLE DOES NOT SAY ANYTHING ABOUT HOW TO ACTUALLY WRITE A PARSER !
And, if i can dare to comment on your statement..
>As for simplicity leading to security, this isn't a supported argument. But as for encoding semantic security issues into your program (security issues outside of memory safety), I would argue a strong type system is the right way to go here, something Rust certainly provides.
This is, for one, a bastardization of what i stated, that was that a DOMAIN SPECIFIC LANGUAGE IS (usually) BETTER FOR A DOMAIN THAT IT IS SPECIFIC TOO THEN A LANGUAGE THAT IT IS NOT SPECIFIC TO THAT DOMAIN. This is particularly evident in parsing, and to say otherwise is dishonest.
As for simplicity being related to security, that should also be self evident. If not from common sense, then from examples of more complex (needlessly complex or otherwise) programs having more faults (on average).
>blah blah blah, literally just vapor at this point, not worth addressing.
Your post is exactly what a fanboy would write. A post that goes point by point, "bashing" them for being "wrong", "imprecise", or "not strong enough of an argument", all the while ignoring the actual "meat" of the argument (the meat being that A LANGUAGE FOR WRITING PARSERS IS BETTER FOR WRITING PARSERS THEN A GENERIC LANGUAGE). It is the equivalent of "link plz" (meaning "scientific paper of GTFO", as if actually using your own brain is a bad thing). In short, you sir are a fanboy.
Meaningless statement - 'fault' in these discussions is impossible to objectively attribute. Is every vulnerability the fault of the developer writing the code, or the tool that facilitated the code? Some would argue the former, some the latter.
The end result is the same - using these tools you can produce vulnerabilities, and your users get exploited all the same. So is fault really important?
> Writing a parser in a memory-safe language does nothing for it's correctness, as memory safety is not the only security problem. One should use a domain specific language, as simplicity is very important for safety.
You have two statements here - one is that memory safety is no the end of safety, one is that simplicity is important to safety beyond memory safety.
The first feels... weak. No kidding - security encompasses more than memory safety. But eliminating memory safety issues limits what you have to worry about.
As for simplicity leading to security, this isn't a supported argument. But as for encoding semantic security issues into your program (security issues outside of memory safety), I would argue a strong type system is the right way to go here, something Rust certainly provides.
> edit: Rust is the new systemd, full of fanboys pushing it forcefully on others (or, as they say, "gently nudging"). I have not much to say against rust itself (except that it is not for "systems programming"), but the fanboys are idiots.
blah blah blah, literally just vapor at this point, not worth addressing.