Will Dormann, a senior vulnerability analyst at security firm Analygence, said in an online interview. “BUT that's only because it was discovered early due to bad actor sloppiness. Had it not been discovered, it would have been catastrophic to the world.”
Is auditing for security reasons ever done on any open source code? Is everyone just assuming that everyone else is doing it, and hence no one is really doing it?
EDIT: I'm not attacking open source, I'm a big believer in open source.
I'm just trying to start a conversation about a potential flaw that needs to be addressed.
Once the conversation was started I was going to expand the conversation by suggesting an open source project that does security audits on other open source projects.
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.
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:
Distribution providers will roll back the package to an earlier compatible version that doesn't have the vulnerability if possible
Someone will fork the project and patch the fix (if the license allows), and distribution providers will switch to the fork
In the worst case scenario if neither of the above are possible, distribution providers will purge the vulnerable package from their distributions along with any packages that transitively depend on it (this is almost never necessary except as a short-term measure, and even then is extremely rare)
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.
That link doesn’t prove whatever you think it’s proving.
That link strengthens my argument that we're assuming because it's open source that the code is less likely to have security issues because it's easier to be audited, when in truth it really just depends on the maintainer to do the proper level of effort or not, since it's volunteer work.
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.
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?
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.
You’re either intentionally misrepresenting the post or you failed to understand them correctly.
You're incorrectly seeing more into what I'm saying than I'm actually saying, probably because you are very invested in defending Linux, and interpret what I'm saying as an attack on Linux.
For what its worth, I'm not attacking Linux. I use Linux as my daily driver (Fedora/KDE).
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.
I just went in and manually edited my display name to my previous asshole of a boss. Two can play this game. If they want to get rid of anonymous content, then let them deal with poisoned content.
That's a fantastically efficient way to destroy their business. There's no way to get honest reviews of employers from employees who know their identities will be exposed whether they consent or not. Doesn't even matter if the review is after leaving that job, future employers can go nosing too.
Because LLMs are slow most of them stream the response to the user.
The response is streamed as text, but generated in tokens.
This means that each "chunk" leaks the length of the text corresponding to the token.
You can then use heuristics to guess the text of the response based on the token lengths.
This is a good reminder any time you are sending content in small chunks over an encrypted channel, many encrypted channels don't provide protection against size leaks by default.
It seems there are a few easy solutions to this:
Send the token IDs (as fixed-size integers) over the network rather than the text.
Pad the text representations of the tokens to a fixed length.
Batch the tokens more (and maybe add padding) to produce bigger chunks and obscure individual token size.
These still all leak the approximate length of the response, but that is probably acceptable.
Yeah, misleading headline. They're talking about the linux desktop, and based just on browser stats. Marked share of linux as a whole, including all datacenters, servers, cloud infrastructure, and heck, throw in IOT devices, android, routers, etc, I'm pretty sure it's the dominant OS already.
IMO the capacititive buttons with no feedback are even worse than the touch screen. at least with the touch screen, you will likely have a colored UI element on screen to press. with the cars that replace all the buttons with capacitive buttons with no feedback, theyre all the same color.
*haptic feedback. The touch and press should be two different actions, not the same action. Otherwise, you need to look at a button to know where it is and if it did what it was supposed to do, which distracts you from driving.
Touchscreens are not that much better in this regard, IMO
I'd be fine with one that works like the Taptic engine on iPhones or how ever the trackpad on my Macbook does. It's a solid surface with no moving parts but it clicks when you press it and it feels 100% the same as pressing a physical button. It's way different than haptic feedback done with just the vibrator motor.
That doesn’t work well in a car though. It works in a phone because you’re holding it, or a trackpad because you’re putting a lot of pressure on it. In a car it’s already shaking from the engine, road, etc. Plus those taps are generally much shorter and lighter and less likely to feel the vibration.
Excuse my French but fuck Apple and fuck their closed ecosystem. I will never buy any of their products.
If some company releases an alternative working on different OSes and based on open standards I will be all in, but I refuse to make a multi trillion company richer.
So you want a product made by some of the world's most talented engineers and designers, costing untold millions for dollars in R&D, but it should not be made by a corporation? How does that work?
It's Vision OS, not MacOS. You can already install Linux on a Mac, as well as any ARM compatible OS through virtualization:
"Apple allows booting unsigned/custom kernels on Apple Silicon Macs without a jailbreak! This isn’t a hack or an omission, but an actual feature that Apple built into these devices"
What do you think would happen if you tried to install Linux or Windows on a Vision Pro? Assuming Apple was to open up the device, what would that look like?
Ok I gotta be honest, it is pretty hilarious that his own company is just like
right so he’ll just go distract himself with rockets or Nazis or tunnels or whatever for a bit, and then we can just turn some of that important shit he didn’t like back on.
Dude thinks he’s Emperor of Man but he’s being managed and handled by his own company (that he himself gutted) lmao
arstechnica.com
Hot