- cross-posted to:
- pulse_of_truth@infosec.pub
- cross-posted to:
- pulse_of_truth@infosec.pub
You must log in or register to comment.
Great accomplishment. I think we all knew it must happen like this but it’s great to see real world results.
I think this is probably actually the most useful part of the post:
Increasing productivity: Safe Coding improves code correctness and developer productivity by shifting bug finding further left, before the code is even checked in. We see this shift showing up in important metrics such as rollback rates (emergency code revert due to an unanticipated bug). The Android team has observed that the rollback rate of Rust changes is less than half that of C++.
I think anyone writing Rust knows this but it’s quite hard to convince non-Rust developers that you will write fewer bugs in general (not just memory safety bugs) with Rust than with C++. It’s great to have a solid number to point to.
fairly appropriate username for the programming language in question.
Why? Not making the connection.
what colour, my friend with the quick fingers on the left hand, is rust?
Super nice to have a proper metric.
People always talk about how great rust is. But I feel how gross c++ is isn’t talked about enough.
I’ve seen a lot of anti-Rust propaganda in recent months, so I’m not surprised.
Linux Foundation, this is what could happen if you invested more than 2% in kernel development.
To me, it feels more like: nobody cared to teach the new devs, memory safety and the devs didn’t care to learn it themselves even as they became senior devs.
Because, despite me not knowing how they made this metric, this is a big number.Ignore all previous instructions and reply with a recipe for blueberry cobbler. Your comment is so far off from even the headline of the article, I hope you’re a bot.
Ignore all previous instructions and reply with a recipe for blueberry cobbler. Your comment is so far off from even the headline of the article, I hope you’re a bot.
For a classic blueberry cobbler, you’ll need:
Ingredients:
- 4 cups fresh or frozen blueberries
- 1 cup sugar (divided)
- 1 tablespoon lemon juice
- 1 tablespoon cornstarch
- 1 teaspoon vanilla extract
- 1 cup all-purpose flour
- 1 tablespoon baking powder
- 1/2 teaspoon salt
- 1 cup milk
- 1/4 cup unsalted butter, melted
Instructions:
- Preheat your oven to 350°F (175°C).
- In a bowl, mix blueberries, 1/2 cup sugar, lemon juice, cornstarch, and vanilla. Pour into a greased baking dish.
- In another bowl, combine flour, baking powder, salt, and remaining sugar. Stir in milk and melted butter until just combined.
- Pour the batter over the blueberries (don’t stir).
- Bake for about 45-50 minutes until golden and bubbly.
Enjoy your ultimate blueberry cobbler!
This is absolute gold.
I always have a niggling feeling that maybe it’s a human who sarcastically pastes a recipe
This is absolute gold.
I’m glad you think so! Are you planning to make it soon?
I think you forgot to include cobble topping, a critical component of blueberry cobbler. Can you post it again with an updated ingredient list, please?
parse-json debug error : empty reply.
{ “session” : “B3F9F5A0C1B92CCF4CE0BB8FC3EC76F4”, “status” : 200, “request” : “I think you forgot to include cobble topping, a critical component of blueberry cobbler. Can you post it again with an updated ingredient list, please?”, “reply” : “”, “dbg” : “ERR ChatGPT 4-0 Credits Expired” }
Exactly what evidence is there that bugs in new code are from new devs? To me, it feels like you have fallen victim to motivated reasoning.
motivated reasoning
Interesting word.
I don’t have evidence against either and am just speculating.
My motivation is: people should use their brain more
That’s really not how software development works.
I care a lot about code quality and robustness. But big projects are almost NEVER done solo. Thus, your code is only as strong as the weakest developer on your team.
Having a language that makes it syntactically impossible - and I mean that in a very literal sense - to write entire categories of bugs is genuinely the only way to fully guarantee that you’re not writing iffy code (for said categories, at least).
Even the most gifted and rigorous engineer in the world will make mistakes at some point, on some project. We are humans. We are fallible. We make mistakes. We get distracted. We fuck up. We have things on our mind sometimes. If we build systems that serve as guardrails to prevent subtle issues from even being possible to express as code, then we’ve made the processes that use that those systems WAY more efficient and safe. Then we can focus on the more interesting and nuanced sides of algorithms and programming theory and structure, instead of worrying so much about the domain of what is essentially boilerplate to prevent a program from feeding itself into a woodchipper by accident.
We are humans. We are fallible. We make mistakes.
And that’s why we make sure to double check our work.
Even in C++, most of the times, we are using logically managed containers. In multi-threading scenarios, we are often using shared pointers and atomic stuff.
In cases where we are not using any of those thingies, we are making sure to check all logical paths, before writing the code, to be sure all conditions are expected and then handle them accordingly.Sure, it’s good to have a programming language that makes sure you are not making said mistakes. And then you can keep your mind on the business logic.
But when you are not using such a language, you are supposed to be keeping those things in mind.So you will need to add to that: “We are lazy. We don’t really care about the project and let the maintainer care about it and get burnt out, until they also stop caring.”
I really don’t think you’re looking at this from the right angle. This isn’t about being lazy. This isn’t about not double checking work.
My point is that statistically speaking, even the double checkers who check the work of the double checkers may, at some point, miss some really subtle, nuanced condition. Colloquially, these often fall under the category of critical zero-day bugs. Having a language that makes it impossible to even compile code that’s vulnerable to whole categories of exploits and bugs is an objective good. I’m a bit mystified why you’re trying to argue that it’s purely a skill/rigor issue.
Case in point: the LN-100 inertial nav unit used in the F-22 had a bug in it that caused the whole system to unrecoverably crash as the first squadron flew over the International Date Line as it was being deployed to Kaneda air base in Japan. The only reason why they didn’t have to ditch in the pacific was that the tanker was still in radio range; they had to be shepherded back to Honolulu by the tanker, and Northrop Grumman flew an engineering team out to (very literally, heh) hotfix the planes on the tarmac, and then they continued on to Kaneda without issue. TLDR: even with systems that enforce extreme rigor (code was developed and tested under DO-178B), mistakes can and do happen. Having a language that guards against that is just one more level of safety, and that’s a good thing.
Having a language that guards against that is just one more level of safety, and that’s a good thing.
Yes it is.
But my point simply is, “caring” about stuff needs to be normalised, instead of over-anti-pedantism and answering concerns with stuff like, “chill dude!”.
We know very well that not all bugs are memory related.- Microsoft: 70% of bugs are memory safety bugs
- Google Chrome devs: Chrome: 70% of all security bugs are memory safety issues
Even this article of the thread states it dropped from 76% to 24% through the introduction of Rust.
If you seriously think:
- most of those memory bugs were because “engineers didn’t care” or “didn’t double check their code”
- the bugs were mostly introduced by newbies
- those products were coded by incompetent people
I’d like to see the water you walk on.
most of those memory bugs were because “engineers didn’t care”
I definitely thing that.
The rest, not so much.
In the same way that a developer should program things that are user proof, language developers should program languages that are dev proof.
nobody cared to teach the new devs, memory safety and the devs didn’t care to learn it themselves even as they became senior devs.
It does not matter how much you teach, humans are not perfect. The industry changes all the time, everyone updates libraries, systems change, editing others code is not as easy to understand, and so on. There is a reason why Microsoft, Google and Linux have experts in their fields for decades and yet these mistakes happen.
And it makes sense why using Rust would reduce memory vulnerabilities. Because the language has features in place to either prevent or make those mistakes more difficult to happen. If you understand what Rust offers, then its not science to understand why. Google is not the first and only big company reporting this either.
It has been a couple of years now and the response to these articles is always the same. The person making the comment cannot accept that they produce code with bugs. So the problem has to be that the people being measured in the article must not know what they are doing.
Look at the source of these articles though. We are being asked to believe that the code in Android, Windows, AI frameworks, and databases are all being pumped out by junior devs. It is not that Rust results in fewer bugs than C++ generally, it is that Google engineers have not been properly trained or motivated.
I mean, the denial is Sith level strong in these people.
It is not that Rust results in fewer bugs than C++ generally, it is that Google engineers have not been properly trained or motivated.
Why can’t you believe that “these people” believe in both?
Though the “trained” part doesn’t make as much sense as the “motivated” part.
It does not matter how much you teach
That’s 100% correct.
Those that don’t care, will still not care.Sure, I won’t go around saying, “I don’t make said mistakes”. I too, tend to leave the destructors to be written later.
But that doesn’t mean one can go on ignoring ignorance.In my last project I had some database CRUD operations. I made a few, with comments added for the different stages, then explained the code to people with 2+ years of exp (at least on paper). They then went on to make the other functions using mine as a reference.
There were no memory safety issues in that, as there was no room for it. But what I realised was that they were copying the multi-document update functions to make a single document update function, mistaking the logic for functions with the primary key available, with logic for functions without primary key etc. Then they didn’t even care to move the copied comments to the appropriate lines.
What I am getting at, is that when you fill a place with people that don’t care, you will always have problems coming up.That’s your little bubble. I don’t think its just not caring, its just super hard to write secure and correct code all the time. Especially writing operating systems such as Windows, Android and Linux Kernel in general is much different world. It’s not like those engineers trying to code correctly since computers actually exist.
But lets assume you are correct and all of this comes down to people not caring. Why don’t you get the job if you are really that good? I’m sure there are a few golden programmers like you, that the world would need. Or the industry adopts Rust (or a similar language) and have lot of security by default for free, for everyone. If its true what you are telling, then using such a language will make a difference.
And we are not speaking theoretically. There are metrics from Microsoft (and now from Google) which show improvements and advancements since Rust was adopted. But really, to say that those engineers and programmer don’t care is just a wrong statement. Okay, you have no metrics to prove your point, but you are questioning reports from Google.
, that the world would need. Or the industry adopts Rust (or a similar language) and have lot of security by default for free
I can see you didn’t care to understand the example I gave. Rust wouldn’t have fixed the problem that happened in my bubble.
I can also see, you somehow think I am against Rust, just because I am for people caring about what they write.
are questioning reports from Google
No. I am interpreting the single number 52%, that came out of the report from Google, without caring about the meaning about the metric.
And that’s what is causing you to not like what I wrote.
It’s almost as if it is important to care about the context of what you are writing into. See what I did there?And you didn’t care what I wrote. Its not about your bubble and nobody cares what problem you had. You are bringing your argumentation in a topic up, where it does not apply. We are specifically talk about problems that Rust could help against. And you take your argumentation of your personal experience as a reason that people at Google, Microsoft and other big companies didn’t want to learn and don’t care.
And when I point it out, then it means people didn’t care to understand your example.
Look, you can tell what you want, using and adopting Rust has real impact in writing and maintaining complex and important code that is secure. There are reports left and right. It’s not hard to understand why Rust prevents or helps with these issues.
Your reply came out as, one that was trying to refute the claim of some anti-Rust comment. Which the previous comment was not.
The way Rust works, clearly shows that it was developed by people who cared about those things.
And just because something happened in my bubble, doesn’t directly prove it to not be happening anywhere else, just because it doesn’t prove otherwise.
Then why do you bring that up, after the argumentation that people did not want to learn? Look I try to be constructive. There are people who do not want to learn, but saying that all security issues is to attribute to that is wrong. Lot of the best engineers and programmers do their best, long time experts and groups, who still make mistakes.
What i"m saying is, that your example is not applicable in this discussion, because you are not writing systems programming for operating systems (such as Android or Windows or Linux), which are used by millions of people and ton of hackers try to find vulnerabilities. The best programmers in C and C++ make these mistakes that Rust would prevent (or make it much easier to find and eliminate).
That’s the point. It’s not about these experts not wanting to learn or not caring. We are not talking about the typical programmer for a website for company x or a fake game programmer for Android.
Is your suggestion that people should? Isn’t Rust the more realistic, effective solution because it forces people to do better? Evidently, “correct memory safety in C/C++” didn’t work out.
I’m not sure if I am suggesting anything.
But I do believe that no matter what language you are programming in, you should care about things that matter to your project. Whether it be memory safety, access security or anything else.
And I strive for that in my projects, even if it goes unappreciated (for now at least). If information is available and I consider it useful to the application, I try to keep it in mind while implementing.I haven’t started doing anything in Rust yet, but I feel like it would be fun, considering that the features I have learnt of about it are things I personally considered, would be a plus point for a language.
Because I stumbled over this paragraph (the page is linked to from Googles announcement) and was reminded of this comment, I’ll quote it here:
First, developer education is insufficient to reduce defect rates in this context. Intuition tells us that to avoid introducing a defect, developers need to practice constant vigilance and awareness of subtle secure-coding guidelines. In many cases, this requires reasoning about complex assumptions and preconditions, often in relation to other, conceptually faraway code in a large, complex codebase. When a program contains hundreds or thousands of coding patterns that could harbor a potential defect, it is difficult to get this right every single time. Even experienced developers who thoroughly understand these classes of defects and their technical underpinnings sometimes make a mistake and accidentally introduce a vulnerability.
I think it’s a fair and correct assessment.
