The main thing is that you can't really know the long-term effects of changing the biodiversity on the planet. It's fairly common that extensive plant breading is producing plants that are less healthy, more prone to diseases. That's why "pesticides" is an argument, but it's not the main argument. What happens when these tomato genes spread too heavily and you will not even be able to produce tomatoes with just soil, water and sun? What if they spread to other plants? (Plants to cross-pollinate).
> The main thing is that you can't really know the long-term effects of changing the biodiversity on the planet.
Has the planet itself not been doing this for quite a long time already? I think your question would be better framed as not “changing” but “accelerating” and I think that is indeed a valid question. I’m just not sure I agree it will end with non viable crops.
I honestly don't see a reason why should Ubuntu make it easy to install downloaded deb files. People who know the risks will just use apt on the command line. People who download random files spotify-1.2.3.deb from the internet are really better served by sandboxed snap package.
Don't agree with this. All of googles apps come via debs (chrome, google earth, etc), as does microsofts (edge, vscode) and numerous other big name applications. They then use the deb to add their apt repository and from then on they are self updating. Deb is actually a great way of distributing an app other than via an app store, and it seems Ubuntu clearly want to kill that.
Ubuntu is mostly aimed at the less experienced user, so it seems OK in that context. I just hope that kind of thing doesn't spread to other distros. If Debian did this, I'd be pretty irritated.
But then you have the problem that enabled this backdoor. It's normal to have uncommitted autogenerated unreadable shell code in the tarball. Nobody is going to review test, it was just generated by automake, right? That makes it so easy to sneak in a line that something slightly different. At least with cmake, you have none of this nonsense, people need cmake to build the project, it doesn't try to save users from it by generating a ton of unreadable shell code.
> Nobody is going to review test, it was just generated by automake, right?
Well, there's your problem. If you have unreviewed code, anything can be snuck in. Doesn't really matter too much where in your system the unreviewed code is.
> It's normal to have uncommitted autogenerated unreadable shell code in the tarball.
You need to review everything that goes into the tarball. Either directly, or indirectly by reviewing the sources it gets built from. (And then making sure that your build process is deterministic, and repeated by a few independent actors to confirm they get the same results bit for bit.)
The social side of this is really haunting me over the last days. It's surprisingly easy to pressure people to giving up control. I've been there myself. I can't even imagine how devastating this must be to the original author of XZ, especially if he is dealing with other personal issues as well. I hope at least this will serve a strong example to other open source people, to never allow others to pressure them into something they are not comfortable with.
It makes Rich Hickey’s „Open Source Is Not About You” [0] particularly poignant.
As a hobbyist developer/maintainer of open source projects, I strive to remember that this is my gift to the world, and it comes with no strings attached. If people have any expectations about the software, it’s for them to manage; if they depend on it somehow, it’s their responsibility to ensure timely resolution of issues. None of this translates to obligations on my part, unless I explicitly make promises.
I empathize with Lasse having been slowed down by mental issues. I have, too. And we need to take good care of ourselves, and proactively prevent the burden of maintainership from exacerbating those issues.
Anyone and everyone in the OSS world should be concerned about this too. You have nation state level actors out there with massive amounts of information on you.
How much information have you leaked to data brokers? These groups will know how much debt you're in. The status of your relationships. Your health conditions and medications? It would not take much on their part to make your life worse and increase your stress levels. Just imagine things like fake calls from your bank saying that debt of yours has been put in collections.
This is why I find some disclaimers in some open source projects quite superfiscial, that the software is provided as is without any warranty. Of course it is, this should be the obvious default.
If there is a law that would entitle a user to more, it is a bug in legislation that needs urgent fixing.
I see this as sort of the pivot on how people choose an open source license. When you feel like you are building the thing for others use a gplish license, it has all sorts of clauses around getting everyone to play nice. Building the thing for yourself however, I think the bsd style license makes more sense. you don't really care what anyone else is doing with it, you don't want to form a community. however, because it is trivial to share source code, you do so.
Look how brilliantly they selected their target project:
(1) xz and the lib are widely used in the wild including linux kernel, systemd, openSSH; (2) single maintainer, low rate of maintenance; (3) the original maintainer has other problems in his life distracting them from paying closer attention to the project.
I am wondering how many other OSS projects look similar and can be targeted in similar ways?
I'm thinking 95% of home automation which is full of obscure devices and half baked solutions which get patched up by enthusiasts and promptly forgotten about.
Controlling someone's lights is probably less important than Debian's build fleet but it's a scary proposition for the impacted individual who happens to use one of those long tail home assistant integrations or whatever.
A lot of home automation controls EV charging these days too. Imagine an attack that syncs a country’s EV fleet to charge in a minute where demand is at a peak. You could cause some damage at the switchgear I bet if not worse
A takeaway for me is to be extremely tight with personal information on the internet. People will use this to craft a situation to fool you.
Are you married? Have a house? Pets? Children? Sick parent? Gay? Trans? Mental health issues? Disabled? All of this can be used against you. Be careful where and how you share stuff like this. I know it's not "cool" to be mysterious online anymore, but it creates a much larger attack surface. People can still engage with groups around these things, but better to do it with various personas than to have one trackable identity with everything attached to it.
We're in a tech slowdown right now. There are people who got used to a certain lifestyle who now have "seeking work" on their LinkedIn profiles, and who have property taxes in arrears that are listed in county newspapers-of-record. If you're an intelligence operative in the Silicon Valley area, these guys should be easy pickings. An envelope full of cash to make some financial problems go away in exchange for a few commits on the FOSS projects they contribute to or maintain.
The Jigar Kumar nudges are so incredibly rude. I would have banned the account, but perhaps they contributed something positive as well that isn't mentioned.
I wonder if it would be possible to crowdsource FOSS mailing list moderation.
There is a good chance that everyone in that thread except the original maintainer is in on the act. It's likely that all those accounts are managed by a single person or group. Targeting just one account for rudeness isn't going to help, if that's true.
The mechanism employed here seems like the good cop, bad cop interrogation/negotiation technique. There is the one person who has taken care to show cultural and mission alignment. Then there are several misaligned actors applying pressure which the first person can relieve.
It does help on the social/psychological side. If you, as an open source project maintainer, have a policy that such rudeness is not acceptable, you are much less likely to become a successful victim of a social attack like this.
It's entirely possible for an evildoer to make someone feel bad while remaining completely polite.
First send a message to the mailing list as "Alice" providing a detailed bug report for a real bug, and a flawless patch to fix it.
Then you reply to the mailing list as "Bob" agreeing that it's a bug, thanking "Alice" for the patch and the time she spent producing such a detailed bug report, then explaining that unfortunately it won't be merged any time soon, then apologising and saying you know how frustrating it must be for Alice.
Your two characters have been model citizens: Alice has contributed a good quality bug report, and code. Bob has helped the project by confirming bug reports, and has never been rude or critical - merely straightforward, realistic and a bit overly polite.
As someone else said in this thread, scammers are often rude, because it makes people act fast, polite responses give them time to think. Of course, people are very easily manipulated. But by completely rejecting rudeness and having the mindset to not let others put pressure on me, you will improve the odds by a lot.
That would be true if you could ban the person from using new emails, but I don't think that's true when the thread if rife with sock puppet accounts. You ban the first rude email account, then there will be 2 new accounts complaining about both the lack of commits and the "heavy-handed mailing-list moderation" stifling differing views.
Yep, as the attacker you bias the entire playing field to your side. If a mailing list has 20 or so users on it, you create 50 accounts over time that are nice, helpful, and set a good tone. Then later you come in with your attack and the pushy assholes. Suddenly those 50 puppets just slightly side with the asshole. Most people break under that kind of social pressure and cave to the jerks request.
Absolutely right. Considering there is a whole cottage industry about asshole replies from Linus Torvalds on linux mailing lists.
For lesser/individual maintainers there is no way to survive this kind of mob attack. Corporate maintainers may be able to manage as it could be considered just as paid job and there are worse ways to make money.
The act relies on there being an extreme reluctance to ban. Once the banhammer has been used, the act kind of falls apart. Of course, difference pressure campaigns can then be brought to bear.
We live in an adversarial environment, time to stop playing naively nice. Ideally it isn't the maintainer that has to do all this work.
Yeah, same. We should be much more willing to kick jerks out of our work spaces. The work is hard enough as it is without also being shit on while you do it.
Yea people are too accepting of allowing asshats like the Jigar messages.
Simple ban and get the fuck out. Too often I've dealt with people trying to rationalize it as much as "o its just cultural, they don't understand". No, get the fuck out.
But hey I'm a NYer and telling people to fuck off is a past time.
Jigar was the same person/group as Jia. They were the bad cop and Jia was the good cop. Banning wouldn't have changed anything. Even if Jigar had been banned, the maintainer would still have appreciated the good cop's helpful contributions in contrast to the unhelpful bad cop. Jia would have become a maintainer anyway.
Not surprising, unfortunately. You'd think malicious actors would be nice to people they're trying to deceive. But after watching a few Kitboga videos, I learned that they more often yell, abuse, and swear at their victims instead.
Being mean is stressful and stops your brain from working properly. If someone doesn't allow you to be abusive, then they are not a mark. Predators look for prey that falls into certain patterns.
>I wonder if it would be possible to crowdsource FOSS mailing list moderation.
I think this could be a genuine use of an AI: to go through all of the shit, and have it summarized in a fashion that the user wants: distant and objective, friendly, etc. It could provide an assessment on the general tone, aggregate the differently phrased requests, many things like that.
Crowdsourcing would works best with the reddit / hacker news model I feel, where discussion happens in tree styled threads, and users can react to messages in ways that are not text, but something meta, like a vote or a reaction indicating tone.
Both of these have significant downsides, but significant upsides too. People pick the mailing list in a similar way.
A big problem is that people allow this sort of thing as part of the culture. I've followed the Fedora and PHP development mailing lists a few different times over the years ans this sort of thing was tolerated across the board. It doesn't matter if you crowdsource the moderation if nobody thinks the behavior is bad in the first place.
Trying to do something about it was called censorship.
The premise of the post I replied to is that the mailing list moderation is currently not great and that it allows people to be abusive. It suggest that we should crowdsource this moderation. I assume they think this will lower the burden.
I myself do not think that this is the actual problem. I think the actual problem is that many FOSS communities have fostered an idea that cracking down on certain types of behavior is censorship. Of course they might all agree to ban somebody who is saying certain well known explicit words or being really really aggressive, but there's a lot of behavior that I would consider bannable but they do not.
I'm trying to avoid mentioning specific cases because I don't wanna either reopen old wounds or cause another similar dustup. I can say that it reminds me a lot of the really old post about the 5 geek social fallacies https://plausiblydeniable.com/five-geek-social-fallacies/ In particular social fallacy #1
Obviously we're not talking about geek culture here (in general anyways). After rereading it, I saw something else that we actually do a see a lot even today.
This in particular has happened on many a mailing list, including the ones I'm not specifically mentioning
>> <SNIP> when nothing smacking of social selectiveness can be discussed in public, people inevitably begin to organize activities in secret. </SNIP>
Well-known annoyances get tolerated for years, and the people who do the work start moving their discussions to bug trackers, irc, or in personal emails to avoid interacting with them.
I agree with this. In group settings I also look out for group-destructive behavior, and address it as best as I can. I'm the kind of person who thinks that certain rules, while restrictive on the surface, enable a sort of sustainable freedom down the line, similar to how the GPL license works.
It's time for more of the big vendors who use these projects in their offerings to step up and give people running these small projects more resources and structure. $20k to have maintainers for each project actually meet twice a year at a conference is chump change for the biggest vendors, especially when compared against the cost of the audits they'll now be doing on everything Jia Tan and Co. touched.
As an OSS maintainer, $20k wouldn't help me enough unless I was retired. The issue is not money (or not just money), but time. If a maintainer has a full-time job, they may not have time, and developers/maintainers tend to have full-time jobs, so...
Now maybe one could build a career out of OSS maintainerships, with work/time funded by lots of donations much smaller than a salary but amounting to a salary.
I was thinking more of a fix to the issue of "who the hell's maintaining this package our distro/service/whatever is based on" than a way to make money. The bigger projects (like the kernel) and vendors (MS, IBM/Red Hat, Canonical, Google, etc.) all have a vested interest in knowing the actual identity and basic personalities of people who maintain the important packages. If maintainers avail themselves for a weekend at a conference twice a year (or maybe even a lighter commitment like a few short meetings with a manager) they get some resources for their efforts. The flip side of this, of course, is that these organizations will prefer to include packages from maintainers who agree to this arrangement over those who don't.
Furthermore, these organizations are in a place to put experienced, trustworthy contributors on projects that need maintainers if need be. If Lasse had been able to go to, idk, the Linux Foundation and say, "Listen, I'm getting burnt out, got anyone?" and they said "Sure, we've got this contributor with an established record who would love to help maintain your project", none of this is happening right now.
I’ve given semi-popular projects that I no longer had the bandwidth to maintain to random people who bothered to email, no pressuring needed. While those projects are probably four to five magnitudes less important than xz, still thousands of people would be affected if the random dude who emailed was malicious. What should I have done? Let the projects languish? Guess I’ll still take the chance in the future.
If it's open source they can just fork it, and if you're no longer maintain yours you can put a link over to their fork. (Or any other active forks). It's still on the user to vet new forms.
> What should I have done? Let the projects languish?
Yes, if you can't find a successor you trust then let someone fork the project and build trust from 0 rather than transferring trust others' trust in you by handing over the project. This doesn't just apply to security concerns btw. - plenty of other ways in which a new maintainer might end up making the project worse (intentionally or through incompetence) compared to it not receiving any updates.
In "Ghost in the Wires" Kevin Mitnik details one of the ways he obtained information was via a law enforcement receptionist* who he managed to trick into believing he was law enforcement over the phone. He obtained information this way multiple times over multiple years, and fostered a phone based friendship with this woman. He seemed to have no qualms in doing this.
He was also turned on by multiple people who he considered close friends. In the book it did not seem that he had considered that it might not be a "them" problem.
*my details may be off here, I read it some time ago
Your experiences may differ, but I'd say pretty much anyone who lived through the past few years has reason enough to pay careful attention to their mental health.
Our brains and other sensory apparatus are extremely adaptable. If one doesn't know anything about the sensation of sound, they can learn to substitute it without it actually being a substitute to them.
I've learned that giving things away is much harder than selling them for a small price. If I want to give something away, I get a lot of interest, but nobody really shows up, nobody is committed. It's a lot of wasteful communication. If I sell it for 5€, it's a much nicer experience and it still goes to the target audience (people who couldn't afford to pay the full price).
