3 ms·

This article indeed did not make sense. The key point it doesn't get is that the majority of issues described in the original were not deeply embedded in the la

by dash2 3y ago

This article indeed did not make sense. The key point it doesn't get is that the majority of issues described in the original were not deeply embedded in the language. They weren't use-after-free etc. They were simply the programmer doing something bad, where something bad is highly domain-specific. There will never be language-level protection against e.g. trusting a URL which you shouldn't trust, or making a function public when it should be private, because languages have to be general enough to trust some URLs and make some functions public. Languages cannot take away the responsibility of the programmer not to do stupid stuff.

deleted 3y ago
[deleted]
xyzzy123 3y ago
Agree you can't kill all the badness, but e.g. web security has gotten better in many respects primarily (I have no proof of this claim but I was a pentester for a long time) because of improvements in libraries and frameworks. I don't think Rust offers anything special in this regard however. Rather I think it is better understanding of the security nuances of particular problem domains that lead to api safety improvements. Devs today are not particularly better at preventing xss or sqli than they used to be but the default tools they reach for have APIs that make it harder to do the wrong thing.
saagarjha 3y ago
Languages can actually help here! They aren't a panacea, of course, but you can do all sorts of things like encode things into the type system ("this is a safe string, you cannot put user tainted input into it without escaping it") or be amenable to static analysis ("this variable is not declared") or even manual code review ("I can understand the entire semantics of this block of code because it is impossible to override the behavior of the operations here").
berkes 3y ago
A fair point that programers mustn't do stupid stuff. But languages (and frameworks) can help a lot with that. When a language (or framework) makes it easy to do the right thing, and hard to do the bad thing, a large category of "stupid stuff" is avoided. I'm lazy, or tired, or stressed, or focused elsewhere. Make it so, that at these moments I'm forced to run extra miles to "do stupid stuff" and we've avoided several bugs (or code smells and such). Like you say, that still leaves the domain logic to make mistakes in. But if we could make our mistakes only there, we've eliminated a lot of bugs too: we only have to pay extra close attention in a fraction of our codebase! Now,we aren't there. Rust isn't, at least. There's still a lot of boilerplate or utility code where I can (and will) do stupid stuff. But rust, with it's proper defaults, secure by defaults, is a lot closer than most other languages. And rusts' emerging frameworks inherit that mindset and help us get closer even.
steinuil 3y ago
> trusting a URL which you shouldn't trust That's actually a feature in Ur/Web, which is a (very niche) language explicitly built for making web servers. It's sort of a domain-specific language though, so maybe it doesn't count. > making a function public when it should be private Nothing's gonna stop a programming mistake like that, but in languages with capabilities[0] you can restrict some functions to only be called when you have certain capabilities, and these capabilities can only be made to be acquired after authenticating a user, for example. [0]: https://borretti.me/article/introducing-austral#cap https://borretti.me/article/introducing-austral#cap

by dash2 3y ago

deleted 3y ago

[deleted]

xyzzy123 3y ago

Agree you can't kill all the badness, but e.g. web security has gotten better in many respects primarily (I have no proof of this claim but I was a pentester for a long time) because of improvements in libraries and frameworks. I don't think Rust offers anything special in this regard however. Rather I think it is better understanding of the security nuances of particular problem domains that lead to api safety improvements. Devs today are not particularly better at preventing xss or sqli than they used to be but the default tools they reach for have APIs that make it harder to do the wrong thing.

saagarjha 3y ago

Languages can actually help here! They aren't a panacea, of course, but you can do all sorts of things like encode things into the type system ("this is a safe string, you cannot put user tainted input into it without escaping it") or be amenable to static analysis ("this variable is not declared") or even manual code review ("I can understand the entire semantics of this block of code because it is impossible to override the behavior of the operations here").

berkes 3y ago

A fair point that programers mustn't do stupid stuff. But languages (and frameworks) can help a lot with that. When a language (or framework) makes it easy to do the right thing, and hard to do the bad thing, a large category of "stupid stuff" is avoided. I'm lazy, or tired, or stressed, or focused elsewhere. Make it so, that at these moments I'm forced to run extra miles to "do stupid stuff" and we've avoided several bugs (or code smells and such). Like you say, that still leaves the domain logic to make mistakes in. But if we could make our mistakes only there, we've eliminated a lot of bugs too: we only have to pay extra close attention in a fraction of our codebase! Now,we aren't there. Rust isn't, at least. There's still a lot of boilerplate or utility code where I can (and will) do stupid stuff. But rust, with it's proper defaults, secure by defaults, is a lot closer than most other languages. And rusts' emerging frameworks inherit that mindset and help us get closer even.

steinuil 3y ago

> trusting a URL which you shouldn't trust That's actually a feature in Ur/Web, which is a (very niche) language explicitly built for making web servers. It's sort of a domain-specific language though, so maybe it doesn't count. > making a function public when it should be private Nothing's gonna stop a programming mistake like that, but in languages with capabilities[0] you can restrict some functions to only be called when you have certain capabilities, and these capabilities can only be made to be acquired after authenticating a user, for example. [0]: https://borretti.me/article/introducing-austral#cap https://borretti.me/article/introducing-austral#cap