*Zero* out of the six pending #curl CVEs are C mistakes.
-
*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)
-
*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 This makes all the Rust people get in the comments like the Spanish Inquisition.
-
@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.
@gloriouscow @goedelchen @floooh @tdelmas The point should not be that a language protects you from doing something bad, it should be that it frees up cognitive resources that are unnecessarily spent on figuring out what a certain construction does. Those resources can then be used to actually understand the code.
-
@gloriouscow @goedelchen @floooh @tdelmas The point should not be that a language protects you from doing something bad, it should be that it frees up cognitive resources that are unnecessarily spent on figuring out what a certain construction does. Those resources can then be used to actually understand the code.
@ahltorp @gloriouscow @goedelchen @tdelmas the cognitive load argument may apply to some gc languages, but definitely not to rust
-
@ahltorp @gloriouscow @goedelchen @tdelmas the cognitive load argument may apply to some gc languages, but definitely not to rust
@floooh @gloriouscow @goedelchen @tdelmas I’m of the firm belief that low-level code should be written with low-level constructions and high-level code with high-level constructions. If that’s possible in the same language, great. If it’s not, multiple languages should be used, but that might of course also have problems.
-
@floooh @gloriouscow @goedelchen @tdelmas I’m of the firm belief that low-level code should be written with low-level constructions and high-level code with high-level constructions. If that’s possible in the same language, great. If it’s not, multiple languages should be used, but that might of course also have problems.
@floooh @gloriouscow @goedelchen @tdelmas Very few people were as stupid as me and wrote large amounts of complicated high-level code in 386 assembly well into the ’90s, but in my defence it was code with no security implications and accepting no input.
-
*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.
zero out of seven now...
-
zero out of seven now...
@bagder it's the lamp post fallacy. Many memory errors are relatively easy to find, making them a fun target for early static vulnerability analyzers.
Leading to a lot of security bugs related to buffer overruns that were found automatically.
Leading some people to conclude erroneously that since they were the majority of security bugs found, they must represent the majority of all security bugs.
AI vulnerability scans will likely demonstrate they were just the tip of the iceberg.
-
@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)
-
R relay@relay.mycrowd.ca shared this topic
. You just have to be extra careful when you write this (do-curl) macro 
