*Zero* out of the six pending #curl CVEs are C mistakes.
-
@bagder You know that's not completely true. They may have happened, yes.
But with a finite time to write and review the code, all the time taken focusing on avoiding "C mistakes" could have been used focusing of the logic instead.
(Also, languages with stronger types do provide states and types encapsulation that can help avoid some types of logic mistakes)
@tdelmas that's just guessing though. Whatever language and environment you pick, you need to work with that environment a bit to find your way. Memory-safe or not.
-
@tdelmas that's just guessing though. Whatever language and environment you pick, you need to work with that environment a bit to find your way. Memory-safe or not.
-
@tdelmas that's just guessing though. Whatever language and environment you pick, you need to work with that environment a bit to find your way. Memory-safe or not.
@bagder Yes. But with C, you have to, first and foremost, focus on memory safety mistakes, because their effect can bypass almost all security implemented. With that out of the way, it really helps to focus on other mistakes.
-
System shared this topic
-
@tdelmas that's just guessing though. Whatever language and environment you pick, you need to work with that environment a bit to find your way. Memory-safe or not.
@bagder @tdelmas also see: https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
...some of those CVEs are also quite embarrassing, and this is a fairly mature project, going back to at least 2019.
E.g. I wonder if some Rust programmers may suffer from an 'overconfidence syndrome' where they think that just using a memory safe language with a strong typesystem protects them from making mistakes, while C programmers learn very early to never trust the compiler
-
@tdelmas that's just guessing though. Whatever language and environment you pick, you need to work with that environment a bit to find your way. Memory-safe or not.
-
@bagder @tdelmas also see: https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
...some of those CVEs are also quite embarrassing, and this is a fairly mature project, going back to at least 2019.
E.g. I wonder if some Rust programmers may suffer from an 'overconfidence syndrome' where they think that just using a memory safe language with a strong typesystem protects them from making mistakes, while C programmers learn very early to never trust the compiler
As a Rust programmer who started in C and knows all about nasal demons, I find that the Rust borrow checker is a constant reminder that "oops, I might have just tried to make a CVE right there."
That you must structure a Rust program of any complexity around memory safety is a constant reminder of what things are and are not safe to do. It's not cognitively free, to the frustration of many people new to Rust. So would gently push back on the idea that programming in Rust leads to laziness. Most languages do not complain at all - in C, you only get interested in safety if you get interested in safety.
I'd also hesitate to call any bug embarrassing, unless it was my own. We've all made some whoppers. These are process failures.
-
@bagder Yes. But with C, you have to, first and foremost, focus on memory safety mistakes, because their effect can bypass almost all security implemented. With that out of the way, it really helps to focus on other mistakes.
@tdelmas yes, and C has existed as a real working option for decades, while memory safe alternatives have not...
-
@tdelmas yes, and C has existed as a real working option for decades, while memory safe alternatives have not...
-
-
*Zero* out of the six pending #curl CVEs are C mistakes. They are all logical mistakes that would have happened anyway even if we had used another language.
@bagder It would have been harder in Prolog.
-
*Zero* out of the six pending #curl CVEs are C mistakes. They are all logical mistakes that would have happened anyway even if we had used another language.
@bagder See, Daniel, couldn’t you show a bit more engagement in putting the bugs where the public expects them? Call it expectation management…
-
*Zero* out of the six pending #curl CVEs are C mistakes. They are all logical mistakes that would have happened anyway even if we had used another language.
@bagder If I'm understanding you correctly... we need a programming language that doesn't allow the programmer to make logical mistakes?
A programming language that doesn't follow logic...Are you re-writing curl in COBOL?
-
-
@bagder You know that's not completely true. They may have happened, yes.
But with a finite time to write and review the code, all the time taken focusing on avoiding "C mistakes" could have been used focusing of the logic instead.
(Also, languages with stronger types do provide states and types encapsulation that can help avoid some types of logic mistakes)
-
@bagder You know that's not completely true. They may have happened, yes.
But with a finite time to write and review the code, all the time taken focusing on avoiding "C mistakes" could have been used focusing of the logic instead.
(Also, languages with stronger types do provide states and types encapsulation that can help avoid some types of logic mistakes)
-
As a Rust programmer who started in C and knows all about nasal demons, I find that the Rust borrow checker is a constant reminder that "oops, I might have just tried to make a CVE right there."
That you must structure a Rust program of any complexity around memory safety is a constant reminder of what things are and are not safe to do. It's not cognitively free, to the frustration of many people new to Rust. So would gently push back on the idea that programming in Rust leads to laziness. Most languages do not complain at all - in C, you only get interested in safety if you get interested in safety.
I'd also hesitate to call any bug embarrassing, unless it was my own. We've all made some whoppers. These are process failures.
@gloriouscow @floooh @bagder @tdelmas "So would gently push back on the idea that programming in Rust leads to laziness." The question was, whether there is an overconfidence syndrome, not laziness.
IMHO, the claim "A language empowering everyone to build reliable and efficient software" is ... uhm... optimistic.
-
@gloriouscow @floooh @bagder @tdelmas "So would gently push back on the idea that programming in Rust leads to laziness." The question was, whether there is an overconfidence syndrome, not laziness.
IMHO, the claim "A language empowering everyone to build reliable and efficient software" is ... uhm... optimistic.
@goedelchen @floooh @bagder @tdelmas
Fair point, my interpretation of overconfidence was that it leads to laziness, but that was indeed not the original point. If you feel something is protecting you, you drop your personal vigilance, vigilance takes effort, thus avoiding effort being a form of laziness.
Maybe a bit of a leap, but it's my brain and I have to live in here.
-
@goedelchen @floooh @bagder @tdelmas
Fair point, my interpretation of overconfidence was that it leads to laziness, but that was indeed not the original point. If you feel something is protecting you, you drop your personal vigilance, vigilance takes effort, thus avoiding effort being a form of laziness.
Maybe a bit of a leap, but it's my brain and I have to live in here.
@goedelchen @floooh @bagder @tdelmas
As for that quote, optimistic as it may be, there's a kernel of truth to it. There are entire classes of vulnerability that are just not really feasible to create in Rust without an unsafe block or really going out of your way to Find Out.
My boldest claim for Rust would be, if you selected some random programmer of indeterminate skill and assigned them the task of writing a file parser that everyone on earth will use, I would absolutely pray they write it in Rust.
-
@bagder It would have been harder in Prolog.
-
@bagder You know that's not completely true. They may have happened, yes.
But with a finite time to write and review the code, all the time taken focusing on avoiding "C mistakes" could have been used focusing of the logic instead.
(Also, languages with stronger types do provide states and types encapsulation that can help avoid some types of logic mistakes)
. You just have to be extra careful when you write this (do-curl) macro 
