This is less a problem with C and more a bad design decision by the musl team. In response to poor practices (programmers not checking what crypt returned), they built an arguably worse one (returning a sentinel value).
Sure, Rust's std::result can make it harder to dumb, but dumb can always find a way.
> You can very well write a Rust function that returns "*" if the password is too long. But the big difference between C and Rust in this regard is that the norms of the Rust community do not allow that.
If safety features are available and you choose not to use them then that's bad engineering.
I love K&R as much as the next guy but special magic ASCII chars multiply defined by convention over 40 years is exactly the sort of rubbish a good type system can protect against (if used).
I did read it. Again, it is blaming poor engineering on C. It's almost like saying people are e.g. stealing because they belong to certain socio-economic group. Crass.
No, this makes sense. You often see people avoid a good solution in early languages, because it's harder to implement. This impacts security, performance, and overall design.
Consider how much easier it is in rust to do tagged unions that won't have the same pitfalls as C's, how much more likely you are to use a rust map from std rather than custom / imported dependency to do that in C, how much more likely you are to do real Unicode processing in rust vs treating strings as opaque bytes and hoping for the best in C. These are things that happen all the time. We can improve design and engineering a lot by simply providing an easy way to get it implemented.
The first time you need a string map in an existing C code, it's often "an event". Do you spend time rolling your own? Do you include a library? How big - are you pulling the whole glib? Do the strings need fancy locale aware comparison? Do you simplify, take a performance hit, and just scan an array instead?
A lot of the time when there's a logic bug and people comment "that's not a memory safety issue, Rust wouldn't protect from it", it's true, but I also think: "but this issue wouldn't exist because enum/type matching would stop it".
There are two big differences between norms and habits: habits are usually individual while norms apply to a community, and norms have a great deal of social pressure behind them.
"It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner"
Oohhh there’s one more C vulnerability. Oh my gosh, what ever will I do? Should I buy a new smart toaster? I’m not sure. I just really don’t know what to do right now.
It’s called pay attention and f*king upgrade your packages.
This is less a problem with C and more a bad design decision by the musl team. In response to poor practices (programmers not checking what crypt returned), they built an arguably worse one (returning a sentinel value).
Sure, Rust's std::result can make it harder to dumb, but dumb can always find a way.
From the post:
> You can very well write a Rust function that returns "*" if the password is too long. But the big difference between C and Rust in this regard is that the norms of the Rust community do not allow that.
People in glass houses: https://github.com/nextest-rs/nextest/security/advisories/GH...
Whataboutery generally makes it quite clear that your arguments are not in good faith.
I just really hate rust compile times man
What does it have to do with C? It's just poor design.
It's like blaming poor driving on one's tracksuit.
If safety features are available and you choose not to use them then that's bad engineering.
I love K&R as much as the next guy but special magic ASCII chars multiply defined by convention over 40 years is exactly the sort of rubbish a good type system can protect against (if used).
I could see the same thing in Python. Except instead it would be an inhandled none they didn’t like so they would return a *.
I think if you read the post you will find the answer to your question.
I did read it. Again, it is blaming poor engineering on C. It's almost like saying people are e.g. stealing because they belong to certain socio-economic group. Crass.
No, this makes sense. You often see people avoid a good solution in early languages, because it's harder to implement. This impacts security, performance, and overall design.
Consider how much easier it is in rust to do tagged unions that won't have the same pitfalls as C's, how much more likely you are to use a rust map from std rather than custom / imported dependency to do that in C, how much more likely you are to do real Unicode processing in rust vs treating strings as opaque bytes and hoping for the best in C. These are things that happen all the time. We can improve design and engineering a lot by simply providing an easy way to get it implemented.
The first time you need a string map in an existing C code, it's often "an event". Do you spend time rolling your own? Do you include a library? How big - are you pulling the whole glib? Do the strings need fancy locale aware comparison? Do you simplify, take a performance hit, and just scan an array instead?
A lot of the time when there's a logic bug and people comment "that's not a memory safety issue, Rust wouldn't protect from it", it's true, but I also think: "but this issue wouldn't exist because enum/type matching would stop it".
It says "the norms of the Rust community" would prevent this vulnerability. So, it's about habits. The terms Rust and C in fact refer to habits.
There are two big differences between norms and habits: habits are usually individual while norms apply to a community, and norms have a great deal of social pressure behind them.
That's true. I just didn't want to keep saying norm because somebody might ask "who's Norm?".
obligatory https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
"It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner"
Oohhh there’s one more C vulnerability. Oh my gosh, what ever will I do? Should I buy a new smart toaster? I’m not sure. I just really don’t know what to do right now.
It’s called pay attention and f*king upgrade your packages.