this post was submitted on 29 Mar 2024
671 points (99.0% liked)

Technology

59742 readers
3927 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 2 years ago
MODERATORS
 

The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project.

“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” an official with distributor OpenWall wrote in an advisory. “Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the ‘fixes’” provided in recent updates. Those updates and fixes can be found here, here, here, and here.

On Thursday, someone using the developer's name took to a developer site for Ubuntu to ask that the backdoored version 5.6.1 be incorporated into production versions because it fixed bugs that caused a tool known as Valgrind to malfunction.

“This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass,” the person warned, from an account that was created the same day.

One of maintainers for Fedora said Friday that the same developer approached them in recent weeks to ask that Fedora 40, a beta release, incorporate one of the backdoored utility versions.

“We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added),” the Ubuntu maintainer said.

He has been part of the xz project for two years, adding all sorts of binary test files, and with this level of sophistication, we would be suspicious of even older versions of xz until proven otherwise.

you are viewing a single comment's thread
view the rest of the comments
[–] CosmicCleric 1 points 8 months ago (1 children)
[–] [email protected] 1 points 8 months ago* (last edited 8 months ago) (1 children)

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.

[–] CosmicCleric 1 points 8 months ago* (last edited 8 months ago) (1 children)

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.

[–] [email protected] 1 points 8 months ago (1 children)

And my rebuttal is three-fold:

  1. Security does not depend entirely on the maintainer, and there is recourse even in the worst case scenario of an uncooperative or malicious maintainer.

  2. 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.

  3. 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?

[–] CosmicCleric 1 points 8 months ago (1 children)

You are intentionally misrepresenting their position.

No I'm not. Or you're assuming my position incorrectly.

[–] [email protected] 0 points 8 months ago (1 children)

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.

[–] CosmicCleric 1 points 8 months ago (1 children)

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).

[–] [email protected] 0 points 8 months ago (1 children)

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.

[–] CosmicCleric 1 points 8 months ago (1 children)

Which means this person is NOT simply a volunteer as you insinuated here:

You're missing this part of what they said, take a second look (bolded part)...

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.

That means they haven't been paid yet, they're doing volunteer work, and they're soliciting publicly for pay to do the work that we would all expect volunteers to do already anyways, making sure their code is secure, which, is my point.

And the rest of that quote...

Otherwise they can fuck right off and I'm going to do what I want with my project.

They're signaling publicly that since they're not getting paid to do the work they can do any level of effort, not just the required (security wise) effort.

We shouldn't assume that full diligent effort is being done to secure the code, just because it's open source and easily readable by anyone. Doesn't matter if there's easy access if no one ever actually looks at it.

I'm not saying it's never done, I'm just saying we should not assume it's always being done (my bet would be more often than not, it's not) and that is a real problem, as this story/situation demonstrates. Capitalism, human nature, and volunteer versus paid work efforts, based on available hours to do the job correctly.

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, because it's really important for all of us that depends on open source efforts to be aware of it and act on it, not just stick our heads in the sand about it.

[–] [email protected] 0 points 8 months ago (1 children)

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.

[–] CosmicCleric 1 points 8 months ago* (last edited 8 months ago) (1 children)

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.

A reminder of the actual tweet...

"tech companies [...] started calling on open-source maintainers to beef up project governance. [...] mandatory two-person code reviews, self-assessments, SLAs, and written succession plans."

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. Otherwise they can fuck right off and I'm going to do what I want with my project.

The point is not what the actual dollar amount would be, the point is distinguishing volunteer work that is currently being done for free versus future paid work that would be done, and to be able to dictate terms and how the work is to be done (security checks, etc.).

So at this point, I disagree with what you are saying, and I stand by what I've said.

Further, it's not worth my time discussing this further with you in particular. Apparently we live in two different realities, and you're completely knowledgeable about open source, where you know for a fact that I am not. Kind of hard the bridge that gap, conversationally. But at the end of the day, I can believe you, or my lying eyes (to quote Groucho Marx).

And actually at this point, after having spoken with you, especially with your latest comment where you stated what work you do/did for open source, I'm more fearful for open source codebases than I was before. Open source developers who take things personally, and with a 'can do no wrong' mindset, they just set themselves up for more security attacks.

Have a nice day.

[–] [email protected] 0 points 8 months ago (1 children)

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.

[–] CosmicCleric 1 points 8 months ago* (last edited 8 months ago) (2 children)

Sorry, realize I told you I was done with our conversation, but after doing so I stumbled upon this video, and thought I would share it with you, as its pertinent to the issue we were discussing.

You keep arguing that open source projects are strict with their code base reviews and such and are as reliable as close sourced products, and I keep seeing others saying that they are not suppliers, and everything is "as is". We can't both be right.

I don't plan on responding to you if you reply to this comment, as IMHO it would be a waste of time, as you'll just twist this video so that its saying the opposite of what its actually saying.

[–] [email protected] 1 points 8 months ago

Here is an alternative Piped link(s):

this video

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source; check me out at GitHub.

[–] [email protected] 1 points 8 months ago* (last edited 8 months ago)

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:

  1. The open source ecosystem does NOT strictly rely on confidence in individual project maintainers because audits and remedial measures are always possible, and done more often than most people are aware of. Of course this could and should be done more often. And maybe it would if we didn't have so many non-contributing freeloaders in the community.
  2. Most of the widely used open source projects are not being done by hobbyists or volunteers but rather by professionals who are getting paid for their work, either via a salary or by commission as independent contractors.
  3. You don't seem to have a firm grasp on how open source software is actually developed and managed in general.