| ▲ | slopinthebag 2 hours ago |
| i think it's just unbelievable there isn't a bigger push to move away from c to languages that can prevent stuff like this from happening. this and just the pure unsafety. it's 2026. it's like pure negligence at this point, the equivalent of building a bridge with matchsticks because you like using it more. |
|
| ▲ | my-huge-pony 2 hours ago | parent | next [-] |
| How would using a language different than C help here? At it's core this bug is a logic bug, where "*" == crypt(x), because crypt in musl started returning "*" in some cases some years ago. This could be Rust. This could be Go. Not every C vuln is a memory safety problem. |
| |
| ▲ | rhdjebejdbd 2 hours ago | parent | next [-] | | Another comment said that returning a * was to avoid returning null which would crash users of the library who didn't check for null. That seems like a C smell to me | | |
| ▲ | ethin 44 minutes ago | parent [-] | | Not really. This is like if the char* were an Option<String> but you had programs which stupidly didn't check if the Option had something and assumed it always did. As others have said, Rust would not prevent this. | | |
| ▲ | K0nserv 30 minutes ago | parent [-] | | `Option<String>` or `Result<String>` forces the check at the callsite. Unlike C, you cannot forget that the function can error. This absolutely helps prevent issues like this. Now, the decision to return `"*"` instead of letting poorly written code crash on `NULL` is not good either. |
|
| |
| ▲ | bmacho an hour ago | parent | prev | next [-] | | > How would using a language different than C help here? Easier to formulate invariants and check/prove them. Better language correlates with safer software. | |
| ▲ | realharo 2 hours ago | parent | prev | next [-] | | >because crypt in musl started returning "*" in some cases some years ago In Rust, the type of the return value would be a `Result<T, E>`, which means the chain of events that led to this would never have started in the first place. | | |
| ▲ | my-huge-pony 2 hours ago | parent [-] | | In C the return value would be NULL, except it was changed by musl at some point. Edit: at the beginning, crypt always returned a value. So hypothetical Rust return type would be a String, and then it would be retained for backward compatibility. Or something else would happen, this is a complex logic bug triggered by a 25 year old chain of events. | | |
| ▲ | realharo 2 hours ago | parent [-] | | The type of the value in C is `char*`. That's what led some people to write code where it crashes without checks. Which is still their mistake. But if the type was something that can't be implicitly used like an always-present value, that would have prevented the situation, even with those same people. |
|
| |
| ▲ | slopinthebag 2 hours ago | parent | prev [-] | | why does this logic bug exist? why are they returning a string, why not a result type, (nil, err), or something else? oh right, because c is a crusty old language with barely any features. |
|
|
| ▲ | ethin an hour ago | parent | prev | next [-] |
| Rust would not save you here as this is a logic bug. Nor would, well, really any other language. I suppose someone might claim that Rust's result type would save you but it really wouldn't: I can easily make the error type a String or pretty much any other type with little consequence. |
| |
| ▲ | K0nserv 34 minutes ago | parent | next [-] | | Rust would absolutely have saved you here. Even with `Result<String, String>`, which is pretty poor design, there's no confusing `Ok(s)` with `Err(s)`. Sure you can go out of your way to write something like let hash = match result {
OK(s) => s,
Err(s) => s,
};
but at that point I feel like the library is forgiven (except for the poor error design).@my-huge-pony does make a good point elsewhere in the thread: if the potential error was not foreseen and the code was written originally to return `String` instead of `Result<String, Error>` then even Rust would be in a pickle. | |
| ▲ | iknowstuff 40 minutes ago | parent | prev [-] | | It would, due to Result<T> and #[must_use] on it. Nobody would return “*” as a sentinel in Rust. |
|
|
| ▲ | anonreplier 2 hours ago | parent | prev | next [-] |
| guess what, this kind of sentinel value mistake could even be made in rust |
| |
| ▲ | woah an hour ago | parent | next [-] | | Cars without seatbelts and airbags chopping off driver's heads in relatively slow collisions? Well guess what, that could happen in a modern car as well if the driver sticks their head out the window while going through a very tight tunnel! | |
| ▲ | slopinthebag 2 hours ago | parent | prev [-] | | no rust programmer would ever return a sentinel string like this. | | |
| ▲ | ethin 43 minutes ago | parent [-] | | Are you sure about that? When backwards compatibility comes into the picture people tend to bend over backwards. |
|
|
|
| ▲ | oguz-ismail2 2 hours ago | parent | prev | next [-] |
| What exactly do you mean "push"? What do you think is going to make musl developers switch languages? |
| |
| ▲ | slopinthebag 2 hours ago | parent [-] | | it's unbelievable to me that there isn't a larger movement of developers to move away from c towards better & safer languages. look at how much pushback the rust4linux folks get, primarily from c developers who are simply afraid of change. imagine engineers not adopting safer building practices because "they prefer the old way"....it's disgusting honestly. what will it take to move away from c? older devs retiring. Planck said that "science advances one funeral at a time" and i fear it will be the same for software. | | |
| ▲ | anonymous908213 11 minutes ago | parent | next [-] | | It will indeed take everyone dying, but it's not because of developers being afraid of change. In large part, it's because of people like you who make Rust insufferable. Rust is the only language I have antipathy for, because of its community. No other programming language broadly has people who make it their life's mission to tell other programmers they're programming wrong because of their choice of language. When your arguments for why they're wrong are also vapid, eg. "C is bad because of an insane developer committed a logic bug that blatantly violates the spec" when an insane developer could just as easily write Rust code that violates the spec in the same way, it reinforces that there is no reason to switch, or at least not to switch to Rust. Rust is a fad among HN-types. It is not used in the real world. You see logic errors reported in C/++ because 99.99% of the world's system code is written in it. The only reason you don't see headlines about logic errors in Rust is because nobody, rounding to the nearest whole percent, uses Rust in production code. Rust certainly does not prevent you from producing the most dogshit software imaginable, eg. https://jepsen.io/analyses/particledb-1.1.4 , which is far worse than any C/++ database anybody uses. | |
| ▲ | bigbadfeline an hour ago | parent | prev [-] | | > what will it take to move away from c? older devs retiring. I'll take forking and porting, thank goodness for LLMs. |
|
|
|
| ▲ | rpdillon 2 hours ago | parent | prev | next [-] |
| musl's crypt function could be written in Rust, Python, or JavaScript, and still return * when the key is too long. |
|
| ▲ | tonetheman 2 hours ago | parent | prev [-] |
| [dead] |