Google is an enormous company which operates flatter than you’d expect for an organization of its size. It’s entirely possible that someone from Google was involved in organizing this (i.e. booking the venue) without having buy-in from leadership. Once leadership became aware after being asked about it, they may have shut the whole thing down because they knew the optics would be bad.
“Instantly” on a geological scale 🙃
Sounds like there are going to be a lot of machines running a fresh install of Linux next year. Microsoft really does ♥️ Linux.
Except it’s actually an “Every language and library that provides this feature” problem because literally no one was aware that this sanitization problem even existed, and Rust is among the first to actually fix it.
The entire problem with cmd.exe was not known and so obviously not documented when the Rust standard library developers were implementing the API, and the same goes for the standard library developers of every other language. Rust was among the first to fix this problem in their API, with many other languages opting to just document the issues instead of actually protecting users from it.
To take all this information and distill it down to trumpeting “Rust has a CVSS level 10 security vulnerability!!” without context is stupidity at best and maliciously disingenuous at worst.
Nitpicking whether the statement can be construed as true within a certain framing just demonstrates malicious intent when the reality is that users of Go, Python, and Java, whose standard libraries have taken a position of Won’t Fix, are in a FAR more dangerous position than Rust users who are actually in the safest position of anyone in any language ecosystem besides perhaps Haskell.
If the issue exists in the standard library of every language that provides this capability and Rust’s standard library is the first to fix it, how is it a Rust issue?
It would be more accurate to say that it’s an issue in almost every language EXCEPT Rust at this point.
The only reason it isn’t being called a C or C++ issue is because their standard libraries don’t even attempt to offer this capability. But you can bet that all sorts of C/C++ libraries that do offer this, like Qt, will also be having this issue.
Funny how the headline makes it sound like a Rust specific problem, as if the Rust language is unsafe or the core team was incompetent, but then other affected language standard libraries include
So actually this is a vulnerability that originates in Windows, and Rust and Haskell are the only languages that are actually protecting users from it as of right now, with Node.js and PHP to follow.
You keep arguing that open source projects are strict with their code base reviews
Go ahead and quote the words I said that suggest this. You have a talent for claiming that people have said things they have never actually said.
The only claims I’ve made in this conversation are:
Nothing about the portion of the sentence you highlight actually implies that they haven’t already been getting paid to do open source work. That’s an interpretation that you’re projecting onto the sentence because it fits your narrative. The poster never identified themself to be a volunteer. I’ve already reframed the sentence for you in a previous post, but I’ll try one more time: “Whenever any tech company is willing to pay me to do work related to my open source project, I sit down with them and talk about my rates” is a semantically equivalent sentence to what the poster said.
You’re also taking one single datapoint which has ambiguous credibility to begin with and extrapolating it to characterize a massive industry that you, like countless others, benefit from while hardly knowing anything about how the sausage gets made.
I’d be surprised if you’ve ever offered a substantive contribution to an open source project in your life, so I won’t be losing any sleep if a freeloader loses confidence in the ecosystem. But realistically you’ll be using open source software for the rest of your life because the reality is that closed source software really can’t compete in terms of scale, impact, and accessibility. If you actually care about the quality and security of the things you depend on, then do something about it. And prattling ignorance on social media does not count as doing something.
Your interpretation is simply not supported by the literal words being said by the person. “we can sit down and talk about my rates” implies that this person already has rates that they charge for the labor they do.
You’re projecting a meaning into the person’s words that simply aren’t there because you want it to fit a narrative that has is not commensurate with reality.
You brought up your credentials earlier so now I’ll bring up mine: My full time job, which I get paid a very competitive salary for, is to develop exclusively open source software. I have many collaborators in the industry, both at my same organization and from others (some non profits, some academic labs, some government agencies, but mostly private for-profit organizations) who contribute to open source projects either full time or part time.
I don’t have one single collaborator who is the mythical unreliable open source volunteer you’re talking about. Every single person I’ve worked with has a commercial or professional (i.e. academic, mission-driven) interest in the developmental health of open source software. When we decide what dependencies we use, we rule out anything that looks like a pet project or something with amateur maintenance because we know if the maintainer slacks off or goes rogue then that’s going to be our problem.
The xz case is especially pernicious. This is a person who by all initial appearances was a respected professional doing respectable work. He/they (perhaps there was a team involved) went to great lengths to quietly infiltrate the ecosystem. I guarantee someone could do the same thing at a private company, but admittedly they’re less likely to have as broad of an impact as they can by targeting the open source ecosystem.
I really wish you would just stop trying to defend Linux and open source development, and listen to the concept/opinion I’m actually stating
I am listening, and I’m telling you that you’re wildly misunderstanding the nature of the open source industry. You, like many many other software developers, are ignorant about the vast bulk of widely used open source software gets developed.
The key sentence in the post you linked which constituted more than 50% of the words being stated by the poster and yet you somehow conveniently missed which completely negates the whole narrative that you’re trying to promote:
Speaking as an open source maintainer, if a tech company would like to pay me to do ~anything for my open source project, we can sit down and talk about my rates.
Which means this person is NOT simply a volunteer as you insinuated here:
When someone suggested a level of effort to be put on code checked in to prevent security issues from happening, the maintainer pushed back, stating that they will decide what level of effort they’ll put in, because they’re doing the work on a volunteer basis.
but in fact is available to be paid a fair rate for the labor they perform. In fact your entire description of the post is mischaracterizing what is being said in the post.
I don’t know how you could have accidentally missed or misinterpreted one of the two sentences being said by the poster, and the longer of the two sentences at that. It was also the first sentence in the poster’s statement. It seems more likely to me that you missed that on purpose rather than by accident. Maybe you’re just so eager to find evidence to match your narrative that your brain registered the entire point of the post incorrectly. Allow me to reframe what’s being said to simplify the matter:
As a self-employed contractor, if you demand that I perform free labor for you, I will decline that request.
Now just add a much more frustrated tone to the above and you get the post you linked.
You’re either intentionally misrepresenting the post or you failed to understand them correctly. I’ll let you take your pick for which is less embarrassing for you.
And my rebuttal is three-fold:
Security does not depend entirely on the maintainer, and there is recourse even in the worst case scenario of an uncooperative or malicious maintainer.
The maintainer you quoted said he would be open to complying with requests if the requesters were willing to provide monetary support. You are intentionally misrepresenting their position.
The alternative of closed source software doesn’t actually protect you from security issues, it just makes it impossible for any users to know if the software has been compromised. For all you know, a closed source software product could be using one of the hypothetical compromised open source software project that you’re so afraid of, and you would never actually know.
If you’re willing to pay a license for a private corporation’s closed source software so you get the pleasure of never being able to know your security posture, then why would you be unwilling to financially support open source developers so they have the resources they need to have the level of security that you’d like from them?
That link doesn’t prove whatever you think it’s proving.
The open source ecosystem does not rely (exclusively) on project maintainers to ensure security. Security audits are also done by major enterprise-grade distribution providers like Red Hat Enterprise. There are other stakeholders in the community as well who have a vested interest in security, including users in military, government, finance, health care, and academic research, who will periodically audit open source code that they’re using.
When those organizations do their audits, they will typically report issues they find through appropriate channels which may include maintainers, distributors, and the MITRE Corporation, depending on the nature of the issue. Then remedial actions will be taken that depend on the details of the situation.
In the worst case scenario if an issue exists in an open source project that has an unresponsive or unhelpful maintainer (which I assume is what you were suggesting by providing that link), then there are several possible courses of action:
The point being, the ecosystem is NOT strictly relying on the cooperation of package maintainers to ensure security. It’s certainly helpful and makes everything go much smoother for everyone if they do cooperate, but the vulnerability can still be identified and remedied even if they don’t cooperate.
As for the original link, I think the correct takeaway from that is: If you have a vested or commercial interest in ensuring that the open source packages you use are secure from day zero, then you should really consider ways to support the open source projects you depend on, either through monetary contributions or through reviews and code contributions.
And if there’s something you don’t like about that arrangement, then please consider paying for licenses on closed-source software which will provide you with the very reassuring “security by sticking your head in the sand”, because absolutely no one outside the corporation has any opportunity to audit the security of the software that you’re using.
Your credentials don’t fix the logical fallacy.
You’re making a logical fallacy called affirming the consequent where you’re assuming that just because the backdoor was caught under these particular conditions, these are the only conditions under which it would’ve been caught.
Suppose the bad actor had not been sloppy; it would still be entirely possible that the backdoor gets identified and fixed during a security audit performed by an enterprise grade Linux distribution.
In this case it was caught especially early because the bad actor did not cover their tracks very well, but now that that has occurred, it cannot necessarily be proven one way or the other whether the backdoor would have been caught by other means.
The fact that it was discovered early due to bad actor sloppiness does not imply that it could not have also been caught prior to wide spread usage via security audits that take place for many enterprise grade Linux distributions.
Congratulations, you’re halfway there! Just two more times and you’ll never catch it again 😁
I don’t think this is a fair comparison because arithmetic is a very small and almost inconsequential skill to develop within the framework of mathematics. Any human that doesn’t have severe learning disabilities will be able to develop a sufficient baseline of arithmetic skills.
The really useful aspects of math are things like how to think quantitatively. How to formulate a problem mathematically. How to manipulate mathematical expressions in order to reach a solution. For the most part these are not things that calculators do for you. In some cases reaching for a calculator may actually be a distraction from making real progress on the problem. In other cases calculators can be a useful tool for learning and building your intuition - graphing calculators are especially useful for this.
The difference with LLMs is that we are being led to believe that LLMs are sufficient to solve your problems for you, from start to finish. In the past students who develop a reflex to reach for a calculator when they don’t know how to solve a problem were thwarted by the fact that the calculator won’t actually solve it for them. Nowadays students develop that reflex and reach for an LLM instead, and now they can walk away with the belief that the LLM is really solving their problems, which creates both a dependency and a misunderstanding of what LLMs are really suited to do for them.
I’d be a lot less bothered if LLMs were made to provide guidance to students, a la the Socratic method: posing leading questions to the students and helping them to think along the right tracks. That might also help mitigate the fact that LLMs don’t reliably know the answers: if the user is presented with a leading question instead of an answer then they’re still left with the responsibility of investigating and validating.
But that doesn’t leave users with a sense of immediate gratification which makes it less marketable and therefore less opportunity to profit…