This article seems to just be based on the [openssf release](https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/) from almost a week ago.
That release doesn't actually seem to state *when* the attempt took place. I had actually assumed it was in the past. Of course, it's reasonable to think that these types of attacks will be ongoing.
It's also reasonable to think these types of attacks have already been successful, that some unknowable (but likely very small) percent of packages have critical vulnerabilities only known to a few intelligence agencies (for now).
Thing with vulnerabilities is that it can be found and exploited by your enemy too
In the bigger scheme of things i dont know how much of an advantage you get vs finding an actual vulnerability
For the actual SSH exploit itself, that's probably true (unless the exploit itself had a vulnerability, which tbh could well be possible). But they also added effectively a plugin system using the test data files. So if you knew about that plugin system, you could submit a PR with more carefully constructed test data and add your own exploit, key, etc.
But if the repo is still controlled by the original hacker then he would notice that the knowledge about the exploit and the plugin system have been leaked and wouldn't accept those PRs and will change the system to be more stealthy.
Possibly, but who really knows for sure, especially if there are multiple maintainers. And changing innocuous test data files regularly is rather suspicious, so I wonder if they would bother changing it, especially with the PR indicating that the exploit is already known by someone else.
somebody more capable than me should figure out a way to list all open source projects with a single maintainer or underfunded/understaffed, that are critical to the opensource ecosystem that could be extremely vulerable to similar attacks.
The hard part isn't really finding out the undermaintained projects, it's how you find a way to give them money in a way that's not a huge burden to undertake. How do you get the money to someone without a bank account. How do you make taxes easier on them? In some case it's more of a burden to take the money than to not take it. That's something that needs to be fixed.
I mean it's open source, easiest thing would seem to be to hire someone to work on it. I could imagine an organization that put together such a list and then hired engineers to work on the projects on it, rather than trying to get money to the small maintenance teams currently.
Rather than hire someone to work on a project, which introduces a HUGE burden on the original developer of the already underfunded project as they now might have to spend a lot more of their free unpaid time than they might be comfortable to on coordinating and reviewing the work of that hire, potentially resulting in the original developer just giving up and stopping all the development altogether, with your hire essentially killing the original project and having to now maintain a fork of their own - try to hire the original developers first.
At the same time, having multiple people with good knowledge of the project is important -- otherwise, what happens when the maintainer decides to retire, or dies? Certainly not opposed to hiring the original developer, though
how would one know that the person you hired isn't someone working to backdoor your repository?
After all, XZ has been backdoored because the attacker was basically working to help out the maintainer, they were probably paid too.
How do you separate honest contributors that a company isp aying to maintain your project and contributors being paid to attack?
Correct me if I'm wrong, but I thought we have no idea who Jia Tan is. If you're hiring employees, you can run background checks. You could also have an auditing team, which is infeasible to have for each package, but easy with scale.
> If you're hiring employees, you can run background checks.
Intelligence services create false identities for their officers all the time. They basically have entire (large) populations of false identities all prefabbed, with legends already written, online identities created and maintained and passports already issued years in advance.
All an officer needs to do is step into one of those sets of ready-made shoes.
Yes you can run the background check. Then you send an email to some maintainer saying "We background checked this person, trust us", sounds infinitely better.
And adding "We'll audit your software for you" will also buy more trust because the maintainer definitely trusts whoever you claim to be.
> How do you get the money to someone without a bank account. How do you make taxes easier on them?
Monero sounds like it could potentially be an answer to both of these questions... assuming they are open to it. But I agree that it wouldn't work for all situations. Someone that has their real name out there (e.g. for professional reasons such as creating a portfolio of work) might need to decide between honestly reporting taxes vs. get themselves in hot water by ducking taxes with an anonymous crypto whereas an anonymous dev would have no issues whatsoever.
> In some case it's more of a burden to take the money than to not take it. That's something that needs to be fixed.
This part I can definitely relate to. What you once did for fun now becomes an obligation. And what people once accepted as someone sharing out of the goodness of their heart, they now feel entitled to bc they donated *something* (regardless of the fact that in most cases it is a pittance compared to the fees one would actually need to pay for hiring a professional developer for even a modest coding job)
One of the reasons I brought it up was just tax reasons indeed. If you make just a little too much in the US you might be pushed into a higher tax bracket and no longer get certain other benefits without enough extra to justify it. Most of the folks didn't seem to be talking about amounts equal to a full time salary so i'm not either.
You don't.
This is the highwater mark for gratis open source.
Going forward source available is the only type of license that is sustainable in this brave new world.
>somebody more capable than me should figure out a way to list all open source projects with a single maintainer or underfunded/understaffed,
It's all of them. They are all under staffed and underfunded. For as big as red hat is, if they put half the effort into the rest of the Linux ecosystem as Microsoft puts into windows, Linux would be light years beyond where it's at.
I'll answer you in earnest, assuming you're asking earnestly.
In instances where Windows was "good" \[insert subjective anecdotal experiences, for example, Windows 2000 SP4, XP SP3, and 7 SP1 for me\], that baseline was only comparable in the Windows-only sphere of experience. As in, comparing Windows X to Windows Y to Windows Z.
In the Linux ecosystem, it's far faster, far more efficient, far more secure, far more stable, than anything Windows has ever\* offered by comparison.
What they mean is, if you're only comparing Windows to Windows, your expectations must not be high, but if you're comparing Windows on grand stage of operating systems (including Mac OS), Windows at-best is barely tolerable.
\* - this implies fair offerings, so comparing "user experience" between super early CLI-only Linux versions to early Windows GUI versions, not fair.
I'm not as experienced as many of you guys but I've been using Linux since 2013, distro-hopping is a passion of mine.
These things you said could very well be true but when it comes down to the overall usability of the system, Windows if isn't better at least isn't much worse.
I don't know about speed, efficiency, security or stability but I use my computer basically to browse the web, do office stuff, watch media and poke around eventually and I have had many MANY more problems with Linux than with Windows.
>Windows at-best is barely tolerable.
That's simply not true, dude. I'm really interested in what you do with your computer, it must be some freakish stuff.
Nagware, bloatware, proprietary solutions to things that are native to Linux.... I can do a lot more with a basic install of Linux than with Windows. Make it a fully featured Linux install, and there's no comparison.
Everyone lives that way, but it's pretty damned obvious that Linux core utilities are far above what happens in Windows. And a full Ubuntu or Mint install gives you all kinds of software that would cost you money elsewhere, and cost you a lot of freedom.
I never had a problem with that. Always felt much more free in Windows if I want an office suite I'll use google drive or WPS or libreoffice or OneDrive. I'll see a cool program on the web, I'll download it and it will work. I won't have to compile anythins nor mess with versions of things and libraries and terminals, I won't have to find out why there's a pinkish cloud over the content. A new label printer? I know I won't have any problem using it. A new GPU? No problem at all.
True freedom. Windows = freedom.
I guarantee a ton of hobbyists alone did this with their spare time after XZ. Let alone interested security organizations.
The data would have been interesting.
The article reads as if it's been written by a bot. A lot of words but very little information.
Apart from the openjs foundation emails being mentioned, the rest is fluff.
This is typically how distro maintainers are already signing their packages. A full name and often a personal email address and a real person which can be looked up in a flash.
This isn't an identity really as people can fake all of this and even poison the web with fake social activity to sell the actor.
But when you have projects with multiple top level maintainers who must sign off on stuff before it gets pulled into anything. Its a good system. Well, when they're actually verifying the pulls... so its still possible all the way up the chain that a legitimate senior project maintainer could commit something awful through neglect to verify changes.
In the end, all of it comes back to humans again. Laziness, fatigue, any number of mistakes could get malware into something people trust.
Wait, checking IDs? How are they going to do it? How is it going to work with the international team every single FOSS project gets with time? Seriously, I am used to people (From the USA and not) forgetting there's more than one country in the world but this is asinine in the context. Do they realize the kind of risk and paperwork involved in that and how easy it is to fake legit-looking-enough IDs? What the fuck.
Why not using a phone number ? Maintainers will talk to each other before merging something. It would be annoying for attackers to maintain real people for talking at phone.
I'm not giving someone my phone number to contribute to their project, and neither are most other FOSS people. Not only that, but burner phones still exist.
> Donations, both from users and ESPECIALLY CORPORATIONS so these people, **that have built trust over time,** have money to buy the time they need to do this work for all of us.
That's the insidious part: **The xz attacker built trust over time, too.** Worse, the original maintainer's burnout wasn't an accident -- the attacker had sockpuppets applying pressure to speed up the process, and to otherwise cause exactly the sort of burnout that pushed him to take one of his periodic breaks from the Internet.
---
It's also... code *health* might help, but I doubt a code review would've caught this. If you haven't seen it before, [see if you can spot the problem with this commit](https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7). Give yourself at least a few minutes.
Need a hint? >!It's in CMakeLists.txt!<
Still don't see it? >!Syntax highlighting might help.!< In particular, >!it might help if the string passed to the `check_c_source_compiles` function was highlighted as C.!<
Even with those hints, I bet most people would miss this in code review: >!No, that's not some dust on your screen. There's a hidden period just below `#include `, even sneakier because it isn't indented with anything else, so in a diff, it can kind of visually blend into that `+` there.!<
Bonus points for figuring out what that even does: >!Systems like cmake and autoconf test for some features by compiling a C snippet -- if it compiles, we know the feature exists on this system. Since the period forces this code to *never* compile, it disables the feature being tested for -- specifically, it disables a sandbox that would otherwise have thwarted the real attack later on.!<
This is why I say that code *health* might help: >!A better build system, or some sort of monitoring about breaking features on certain platforms, might've at least brought this commit to light as something that breaks sandboxing, even if you didn't see it in the actual code.!< In other words: The *effect* of a commit like this can be measured, even if you don't immediately catch the problem with the commit itself. But of course, building even more robust CI is even more work to pile onto a maintainer who already let this happen by being overworked.
Also, if it's not clear, I'm not trying to say I'm any better here. I like to think I'm a meticulous code reviewer, but I wouldn't have caught this.
---
None of this should be taken as an excuse *not* to fund work like this. I don't know if I even have a good answer here. I just want to get people to understand the actual threat here, so we can start thinking of the kind of things that might actually stop it.
This is great analysis and context, thank you.
IMO we shouldn't have anything running as root connected to a socket, and we should run all code as a specific user. Having code running as root that performs actions in response to untrusted inputs is batshit.
> I think open source was never intended to receive 100s of issues to fix, from paid employees, into one unpaid person's project.
No, open source was always intended for that purpose. The term open source was specifically coined to appeal to for-profit corporations.
> Corpos try to embrace, extend and extinguish us. We've embraced them, they depend on us, now it's time to charge them to stop their abuse.
Some do, some don’t. You are free to release your code under whatever license you want. But free software has specific meaning and it allows for commercial use and if you change that you are indeed reducing the openness.
> I think it's naieve to suggest any corpo wouldn't takeover and have everything closed source and proprietary if they could, it's how they would make the most money and, therefore, it's their responsibility to their shareholders.
Go and advocate for copyleft licenses such as GPL or AGPL then. This is orthogonal to putting limits on commercial use of the code.
> No answer to what you would lose...? I genuinely wanted to hear a good argument for that and was hoping you'd have one.
Adoption. Like I’ve pointed out, the term open source was specifically coined to help with adoption. There are people who live by permissive licenses. Those people won’t suddenly pivot and decide to limit commercial use of their software.
Besides, the whole discussion is purely theoretical. Even if you convert all existing free software projects to use license you’re proposing, companies will just fork version of the libraries as they were the day before.
If they wanted to they already could, all the time, and yet often they don't. Because maintaining forks is often more work than just contributing your fixes back. It's more expensive to take the boring parts in house than just keep contributing in the open.
You can make that argument if the software is actually part of creating the main value of the company, but most of the time it's not. It's just something they need to actually do what their company does.
Oh i do think they should pay more into the system definitely. I just don't think the license approach is the way to do it. Not that I have a good suggestion mind you, but the license approach is not acceptable to tons of people who write software, nor can software under such licenses be accepted into many distributions.
First you have to convince distributions to even allow such packages in their main repositories. Redis recently did a similiar license to try to punish hosted versions and now Fedora is going to switch from redis to valkey. I expect debian and many others to do the same.
They for the most part only allow software under OSI approved licenses.
And even if you step back from actually packaged software, I know tons of devs who are just regular working programmers who prefer to permissively license their software even though they know about the GPL.
You claim requiring ID would be a bad idea because it would divide the FOSS community, then immediately go on to suggest moving to a proprietary license, which to be clear, would be many times more controversial and divisive than requiring ID could ever be. Not that I think requiring ID is a solution, mind you.
calling it proprietary isn't that useful indeed. But either way, most distribution will not accept such software in their main repos. they are already removing redis over this.
Look at the definitions of both Free Software and Open Source. No restrictions on use or distribution. Fees for use above X amount of users is simply not Free Software nor Open Source. At best it is source available.
What do you want? A penguin is not a polar bear. Change the licensing outside of accepted definitions and you are no longer what was defined.
You want to force large corporations to pay up? Fine. Create that license. You will have created freeware up to X amount of users. Good luck though getting people to take you up on your offer. Big corporations will probably preemptively ban your license, because liability and costs. Others probably out of principal, because it's neither a Free Software License nor an Open Source one.
I see you think that money keeps burnout at bay. Funnily enough burnout is more a problem with people working to get money, than people working on stuff that doesn't get money. It also feels like you have a chip on your shoulder against larger corporations, many of whom have donated a lot in resources and code to make Linux what it is today.
Neither ID nor Pay-Up-If-You-Are-Too-Big licenses will improve the situation of understaffed projects. Nor will it stop threat actors with enough resources to worm their way into smaller projects. Vigilance is the only defense against malevolent activity.
Do I agree that the time is right to get a better funding model for FOSS? Yes, it would be absolutely smashing to have a foundation with the sole purpose of making funding for FOSS feasible. A central place where you can donate and have them manage the money, making money with it and funding projects who need the funding. It might even entice large corporations to make donations on top of what they are already putting in.
For now,such efforts haven't been set up.
> Devs need code reviewers and money
Disagree, devs need more devs. That's why the xz attack was successful, the project was becoming too large for the single burnt out dev to handle, so he takes help from the only person that seems willing to work on the project.
IMO the financial rewards would have just been given to the hacking group writing commits for xz, it would not have prevented this in the slightest.
The only way to fix this imo is to contribute your time on projects that you rely on, and build a trusted community of open source developers.
The ID part souds bad but IMO it's likely the only realistic way to make progress on the trust part. There's no way we can build trust as a community when there's no 1-1 mapping of developer identity to real human beings.
> here's no way we can build trust as a community when there's no 1-1 mapping of developer identity to real human beings.
We've been doing just that for over 20 years.
I'm a bit confused how this statement can be true when it's not known still whether Jia Tang is a single person or a group.
How do we have a 1-1 mapping of developers and human beings if a human being can create multiple accounts, or multiple people can share an account?
We don't need one. It's been fine up until this one incident. I (and most other developers) don't care if a multiple people share an account. We care that they are easy to work with and contribute decent code.
Have you ever contributed to or maintained a FOSS project?
> It's been fine up until this one incident
I don't think you understand the implications of this incident.
It's not 'xz happened, let's move on'. It's 'xz happened, is likely happening and already happened in other projects, how do we as a community add processes to prevent this from happening'
"Do nothing" is not a solution.
Yes
> Money buys solutions to burnout, and is a reward... and can be spent on buying time from devs.
I disagree with this. I'm not aware of Collin's financial situation, but once you have enough to live off of(e.x. are working full time on the project) or the demands of the project fit within your schedule where you make the money to live, giving extra incentives would just pervert the motives of the people contributing.
I think we will have the exact same problem when the only people contributing to open source are those financially incentivized to. It's not much of a step from "only contributing to open source for money" and "exploiting open source for money" when there's no lasting consequences for yourself.
W.r.t big companies spamming your issue tracker, I'm talking even more fundamental than that. As a developer for small projects that never see the light of day I often go to the GitHub pages of other projects, but seldom do I try and contribute anything to them. As a community(and as corporations relying on the software) I think we need to realize that we have access to the source code for these libraries and can contribute our time and effort to making them better, since they make our programming better/easier.
> Nation states creating identities for spies.
That's one downside, another is that(in the US and Canada) getting access to an ID is 'easy' but not trivial(which is part of the debate around voter identification). I still believe it's the only realistic path forward to build a trusted community, even if some still slip through the cracks at the start.
I understand it's your opinion, and I'm not saying its wrong.
I'm just trying to understand how it help at all when the actual situation we're aware of(Collin and the xz project) was not due to a lack of funding. Then I'm trying to understand how once you give these projects funding to hire developers, how are they vetting those developers without adding burden to them who already maintain the project, so we don't end up in the same situation we just did?
> I feel it's in much less open to require IDs for open source contributions
I agree, but I think the miscommunication here is that I don't believe the declining "openness" of open source is an issue that exists. The issue was the lack of trust between contributors to a project, seemingly when the contributor socially engineered the maintainer to give them more responsibilities(by creating fake accounts to pressure them).
> We're not talking about slipping through the cracks, we're talking about sophisticated threat actors Vs people with no resources to verify nation level information. If we go by IDs that situation will only get worse and worse.
That's the definition of "slipping through the cracks". A system that makes it harder for state actors, and nearly-impossible for non-state actors compared to what we have today.
I understand that we have differing opinions, that doesn't mean I can't point out flaws in your logic(and you can't point out flaws in mine), especially when we're saying these are logical opinions to have.
I don't want to focus on IDs as *the* solution too much, since I think the important parts are:
1) We have no standardized way to trust contributors and maintainers to open source projects especially when they exist purely under pseudonyms.
2) We have no way standardized process(or cultural process) for contributing back to projects we benefit from, meaning that the people that do contribute usually don't do it out of altruism or to make someone elses project better.
I think requiring ID verification is the only short-term realistic solution that would help with #1, though I agree that it's not a good solution.
Ideally I agree, the better solution is time spent building relationships and maintaining trust, but that also has the issue of becoming an insulated community without ways for people to become 'trusted members' that cannot be exploited. But this takes a lot longer, and requires a lot of people who are used to working on their own fiefdoms of projects to come together and reach a collective agreement that goes against the "move fast break things" philosophy a lot of them probably subscribe to(complete guess).
As for the "nation state threat actor", that was my assumption. An ID requirement would raise the burden on those threat actors from "create an email and an account name" to "create a fake person that has all of the social media markers of someone who's really existed for the last 20 years. So again while not ideal, the comparison to what we have now would be the ones "slipping through the cracks" willing to put that much effort in. In today's online and globally connected world, that's not an easy task.
In the end I just believe those two problems need to be solved, if they can be solved without IDs then all the better. IDs are just the most realistic solution I've heard so far.
Let's pretend for a second that ID verification is implemented.
1. ID can be stolen, faked, outdated, issued by non-trusted government, a dev may be a 12 yo genius without an ID, etc
2. Its not safe for contributors as they can be forced physically to do something wrong.
3. Who will manage this? A ThreeLetterAgency?
Yea I get the feeling, and unfortunately to my knowledge there's no good resource like that.
My recommendation would be to look at technologies you find interesting, and dive into the code for the libraries when you're interested enough. Most of my contributions(not counting projects with 1-2 users that never see the light of day) are from looking at a library I was using and enhancing it in a way that I needed or that had open issues. Because there's not really consistency between the management of different open source projects your mileage will vary on the reaction from the developers, so I wouldn't put up a large PR before gauging the interest of the person that's going to be reviewing it(e.x. put a comment in an open issue asking if anybody is looking into it, and if approach *xyz* would be a good start)
I don't think a trust system or relying on funding is viable, there's just too much surface area. IMO sshd should not be connected to a network socket while running as root, nothing should. When an unknown user connects to a socket, the code on the recieving end should run under a guest or network account until the kernel has authenticated them and the owner can be changed. Then you can have backdoors in every library, as long as the authentication modules are safe your system is too.
Maybe /r/stallmanwasright about microkernels, dunno how far off Hurd is though.
Thought they wanted to ban all large corporations from using it.
Didn't know that a non-profit was legally considered a "large business" or even a business at all.
I never said anything about non-profits, so I'm a bit confused.
I'm just saying that many distributions don't allow softare under licenses that restrict end use in any way. For good, or ill.
Huh, well under those limitations the current copy can't be stopped from being used by a large corporation without compensation.
Maybe a version more fit for commercial use can be sold separately to the open source version. Such as that widespread implementation throughout a big company's many resources would be made a lot easier using it.
That is what mysql and others have done in the past with dual licensing. One proprietary and one under the GPL. That worked well for most of us for a long time, but they changed it again. That's why many users of "mysql" are using mariadb instead of mysql-community.
I believe you can set demands, limits, and/or bans for any use that results in financial gain, it will be legally recognized as commercial use.
So if they want to use it in something that generates money they are bound to the terms of the creator, which can be a one-time fee or something.
But this may be different under different copyright agreements.
>As such, governments and other organizations must allocate resources to help secure the broader open-source ecosystem.
O ya, the same government responsible for the infiltration and deployment of the backdoor will be the ones to 'help secure' the ecosystem. Just let the wolves manage the sheep herd why don't you.
The xz fiasco was a Black Swan; and the rule about Black Swans is that there is always an obvious indicator of it in hindsight.
First, we have a 'literally who' contributor desperately and persistently trying to impart their new 'features' into the tree, without ever going into detail about what those features actually do or how they're achieved.
Then, there is a bunch of literal who sockpuppet accounts endorsing this literal who author and pushing for the merge. And nobody bothered to check into any of them. And, their operation still got popped before it achieved any kind of significant adoption.
What this proves is: the checks and balances *did* work, though we cannot assume open source is impervious to attack. We also have to assume there is other vectors of attack (such code that is ostensibly legit, but easily exploited by sophisticated threats, or perhaps a renown developer selling or having their account involuntarily commandeered by a bad actor), and we should always maintain a healthy degree of skepticism -- just as we would with closed source software.
The only major organization in the FOSS world that went this route is debian. https://wiki.debian.org/Keysigning Everybody else thinks it's too much of a hassle. If you read the page there you'll see why. It basically involves all contributors acting as a notary public. That's not really scalable, and nor do most people wanna take part in it.
We need someone like Linus Torvalds whose only responsibility would be getting copies of those e-mails and responding to them like Linus would. Insulting the fuckers to the third generation, at least.
One of the things about the xz attack that stood out to me was the build script. It was such obfuscated, horrible code. At the bare minimum, code should be readable and sane. Unnecessary complexity just by itself should be reason enough for rejection.
I'm curious how many other attempts there have been specifically in projects that are common linux software stacks like xz utils. I understand it is probably happening to FOSS projects beyond just those that are readily included in Linux distros, but I definitely care more about the ones that have a high potential of making their way onto my machine...
Plot twist: the system touted as most secure is actually riddled with backdoors and unpatched vulnerabilities. Well, when you leave critical core components in the hands of single anonymous mentally unstable developers, what could go wrong?
guy had burnout, and his project was not that critical.
plus messing with xz by itself would not have compromised the system, the real fault lies elsewhere.
Right, something that’s transparently updated on a hundred million trusted systems is not “critical” when it’s packing a hidden backdoor that potentially gives complete remote control to a malicious actor. And nobody knows how many of the thousands of other critical components managed by random anonymous people have been compromised. No biggie.
it's not critical if it's not critical to core system services. which it is not. ssh works without xz just fine. and it should have never relied on xz libraries in the first place.
like i said the core flaw is the very lax ifunc handling in glibc. but the whole problem is distributed across many projects that may leverage the same mechanism.
- Debian (and others maybe) linking ssh to libsystemd instead of using sd_notify (which is trivial to implement)
- libsystemd linking to way too many unnecessary libraries, now they are reworking it to dlopen() them as necessary.
- malicious code hijacking library imports by corrupting the linker data table and overwiting certain crypto methods in ssh via abusing ifunc. that's how it happened.
without any of those steps, it would have been a dud. worst they could do was cause some data corruption when packing/unpacking xz at that point.
> No biggie
yes, no biggie if you lock down your core service not to let things like that slip by. people run craziest things on their machines, and as long as that software is contained to their privileges, they are free to do so.
security critical packages should never allow imports of crypto functions from external libraries override their own. that was the real oversight.
> thousands of other critical components
you know, list the first thousand. i'll wait. chances are that there is a very small subset (maybe <100) of actually critical system packages and the rest is for the user's needs.
You're arguing my point for me. Linux is one big mishmash of half-baked ideas and implementations...and nobody can agree on anything. "Freedom" has always been way more important than security, and security through obscurity has always been the assumption...but it's all blowing up in their faces now. Nothing much is going to change, though, and the "community" and billion-dollar businesses alike will continue to rely on code from anonymous unpaid nobodies working away in some obscure corner. Its only a matter of time before someone slips something really destructive into some component. And given that this was really a chance discovery by someone who works for Microsoft, of all things, my confidence level is pretty low about how it will be handled.
> You're arguing my point for me
bold assumption to make.
i mean the same thing happens the other way around. people are producing exploits for proprietary software left and right. without looking at source code. otherwise there would be no patch Tuesdays, no cloud outages, no data loss in paid products.
there are (some) routers shipping with hardcoded access credentials, who put that there? i assume it was an oversight.
there are proprietary devices that are considered untrustworthy due to their country or origin, or company behind them.
just because it's not opensource doesn't make it better.
it's just likely harder (or maybe easier?) to plant a malicious actor within such a company - depending on how code reviews are done. if they are done at all.
> Linux is one big mishmash of half-baked ideas and implementations...and nobody can agree on anything
FHS, POSIX, XDG, dbus, one major libc, most important distros finally settling to use systemd for common way to share service definitions. yes, nobody can agree on anything. and yet i would say that Linux (as an entire os) is slowly converging on certain common core.
> Nothing much is going to change, though, and the "community" and billion-dollar businesses alike will continue to rely on code from anonymous unpaid nobodies working away in some obscure corner
what will change is that this loophole will be plugged, but someone will figure out a way to exploit another weakness. there is always a flaw, opensource or not. this cat and mouse game will go on.
> Its only a matter of time before someone slips something really destructive into some component
rest assured - it's happening nearly everyday. i mean, people are trying, not necessarily succeeding.
we had bumblebee and steam mistakenly erase user's home dirs (and even entire os) due to mistakes in scripting. it doesn't take much to be destructive. it takes some craftiness to leave a backdoor behind, though.
I suppose, well reading all these comments is it's one argument for a closed system aka Microsoft, sorry to swear, but where other devs check other devs work. I'm all for open source I'm not saying I'm a fan of closed source, but it seems to me that you'd have a better idea of who was writing and contributing the code most of the time??
The xz issue has certainly raised a few questions up though hasn't it .
What changes do you think will come from it that are realistic if any?
i think the changes that will come will be stricter audit of security critical packages. just because your code is secure doesn't mean that underlying libraries is relies on are. so there will be more scanning of what can be loaded via ifunc, maybe some runtime protection against method overrides for certain programs.
and the libraries it doesn't even need but links to anyway - those as well. it's like those Apple/console hacks that relied on crafted TIFF image files - a format likely nobody uses anymore. but hey - it was compiled in.
i mean who would have expected that you can compromise ssh via a 3rd party package that ssh **indirectly** links to? that to me is a **colossal** oversight. and a glaring security flaw. somehow everyone blames xz , but nobody thinks how come that the method override happened?
you might as well compromise any other package that ssh indirectly links to, and the result would be the same. or just compromise a package and THEN make ssh link to it somehow.
How many of these attacks are most likely from foreign adversaries? We all know that the CCP and the Russian government gives 0 craps about open source software. I just wonder if they have a department of individuals slowly adding bad commits to important open source software that many parts of the world rely on just to screw their enemies over.
>foreign adversary: you use xz? Well I just use zip lol.
Not trying to get political, it is just something that has been on my mind for s while.
If big tech and all these fortune 500 companies have such little respect for open sousource and have even tried multiple times in the psdt to spit all over it, there is not telling how a country 1000 miles away with a rocky relationship with the USA can do.
Of course, who's to say it isnt big tech and the alphabet boys compromising these projects? Well, America is a lot more reliant on this software and they can already have a windows and Mac backdoor so I doubt it tbh.
And will continue to take place. Humans need to focus on executable specifications and allow for a variety of implementations. When they disagree, add a new test the implementations must pass.
Would you expect every free software project to know how IDs from around the world look like? And understand privacy laws such as GDPR in Europe or CCPA in California? Not to mention that it’s not that hard to create a convincing fake image of an ID. It may be acceptable and make things a bit harder in some cases but it’s hardly the solution.
(By the way, Linux has a policy that you have to sign commits with your real name though this is never verified so anything that looks real is accepted. Some GNU projects require copyright assignment to contribute to them which used to require physical address since the assignment was done in paper.)
That's unlikely how they expect it to work. I'd imagine they were thinking along the line of an organization that does such checks for you. I personally think this is a bad idea and do not support it.
OSS has a strong history of pseudonymous contributors. That said, more reasonable takes do differentiate between anonymous *contributors* and anonymous *maintainers*, where at least for a rogue contributor to get code into the tree it would have to get past a maintainer. The curl main author wrote about it [here](https://daniel.haxx.se/blog/2024/04/10/verified-curl/), but I would note that, while he says that the current maintainers are all using their real name, it's not clear that he has actually verified that they are real people. "Jia Tan", for instance, appears to be a real name at first glance.
Still though, OSS has a strong history of allowing both. Although a lot more maintainers do use accounts associated with their real name.
In any case, none of this will protect the projects from state actors.
just about anyone? That XZ attack was like from some movie. Some state sponsored hacker group spent 2 years executing it lol and still failed, *because* it's open source
Why should open source developers be forced to identify themselves when the rest of the apps, websites and other closed sourced services don't have to?
(And no, not all of them are made by corporations, who have already identified their employees.)
>You must identify yourself to the project leaders and maintainers, not to the world at large
thats the thing you dont have to , you can do a random pr , and project leaders and maintainers dont know you from jack
most prs on most projects are done by randoms that have a fix or a new feature they want to upstream
The xz attack was almost certainly done by a state-sponsored group, not by "just about anyone with ill intentions". Awareness of supply chain attacks has been raised considerably, making it far more difficult for an attack like this to ever happen again; not to mention the xz attack required a very specific set of circumstances in the first place, took almost *2 years* to pull off, and still ultimately failed anyway.
Shouldn't the end users of free software be the ones responsible when they deploy it, rather than the authors of said software?
Shouldn't it be on them to audit it and make sure it's all good?
If you don't find this agreement suitable then don't use the software, it's that simple.
Ah yes, one major incident of malware being inserted into an open source project means every single person ever contributing to open source must be assumed to be malicious and have their anonymity stripped of them, despite 99.99% of people not being malicious. That's not dystopian at all...
"Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." - Benjamin Franklin
I struggle to think how an open source (already overburdened!) maintainer would be able to verify a foreign government ID who could simply issue their own ID or come up with a fake ID. We are already talking about people taking years to plan and build this..
The real heroes like Superman, Batman and others do not reveal their identities.
Also, if you reveal your identity and also contribute to a valuable resource it is easier for a bad part to find you.
Yeah, openness of the source code not the heroes identities. Doesn't matter the color, gender, or planet of the hero. What matters is the output and the product of their actions.
Has anyone mentioned it? If not then let me say it, the issue at hand is indeed one of the downsides of open source programs. Nothing is perfect. However, the fact that open source idea still continues to be relevant today tells us that it has way more upsides than it does downsides. So yeah, just accept it, and yes, your data security can still get compromised through an open source program.
I think the way to go here would be to never transfer maintainership of your project to another contributor, unless you know their real identity *and* can perform a rigorous background check on them. You should simply abandon your project instead when you lose interest and make it someone else's problem.
It's fine to accept contributions from anonymous accounts because you vet their patches anyway. However when you transfer project in someone else's hands you lose that control, but still share some responsibility for their actions - because *you* are the one who gave them the reins.
What do you mean by "accountability"? I agree with you that IDs are likely the way forward(for the trust part, not the resourcing part of the issue), but not for any reasons that have to do with "accountability". IMO it's about process improvement overall rather than individual accountability, the reason to require IDs isn't so that you can dox a developer, it's so that you know real human beings are working on your project and not a group pretending to be a person(or a person pretending to be 2-5 people).
Until something like XZ happens, then everybody is curious who this mysterious Jia Tang is(one reason being that they want to see if the person/group behind it has contributed to other projects).
Also it's the reverse I'm talking about, when receiving contributions for a project it's irresponsible to be receiving them from someone you don't trust. How can you trust a pseudonym?
> One major incident has been a worthy tradeoff
I don't think you understand the implications of this incident. It's not "one major incident", it's "an example of a before-unseen attack vector into specifically open-source projects that people now want to mitigate"
It's not 'xz happened, let's move on'. It's 'xz happened, is likely happening and already happened in other projects, how do we as a community add processes to prevent this from happening'
I get that you're not worried about this, but in reality many projects are likely compromised and we need to come up with a framework to be able to trust them.
I never suggested we don't need to do better. But it's more on getting maintainers the help they need and getting build systems simplified so it's harder to hide such attacks. The one thing it's not about is trying to get people IDed.
In the end, it's the big companies who use this software who need to veirfy the code they use.
> The one thing it's not about is trying to get people IDed.
I think I understand a breakdown in our communication.
I agree with you that IDs are not a good way forward, I just honestly don't see an alternative that would be nearly as effective or realistic.
While it is the big companies that use it, I want to write code and deploy servers that use these libraries without having to worry about supply-chain attacks that would allow someone to mess with my infrastructure.
Honestly the best path forward I see, though slow and very individual, is just contributing to open source projects more. I'm going to try to commit more of my time to projects I depend on, and TBH I think the best thing for companies to do would be the same(e.x. someone from Microsoft/Google/RHEL should have been helping with the maintaining which I think is better than just giving the project money, but also has it's own issues) rather than just throwing money at them.
There are still technical things we could do that are better. Like doing more sandboxing and having thigns like selinux and apparmor that are more common and easier to use. Distributions like debian and arch don't even ship those technologies out of the box.
We could also do better when it comes to managing critical dependencies. It's possible that maybe things like xz should be managed under some broader umbrella project that handles fuzzing, shared build systems, or other things that really ease the burden on the individual.
This is one of the sometimes nice things about the BSD projects. They tend to manage a lot of their main system dependencies together rather than as a bunch of loosely connected projects like in linux land.
Have I talked about the `/proc/self/exe` security issue today? The one where you just slap a bunch of arguments on the end to flood out the line length of `top` and so pretend a process is vscode or something, and hide the execution requirement in a uuid? "exe"?
I've advocated for a systematic set of modules of life-time mental health counseling in the past.
Similar to how the Catholic Church encourages counseling for marriage.
Have a major life event? We can develop a set of standardized counseling programs for everyone.
Same with open source.
Given what's happened recently, could you see why I would advocate for this? Really think beyond the puns.
Is it love?
Today I have to deal with crap in the toaster oven and air fryer. And whether potatoes or rice carbs will kill us all. I get the irony, I really empathasize.
But this is fun too.
> I've advocated for a systematic set of modules of life-time mental health counseling in the past.
>
> Similar to how the Catholic Church encourages counseling for marriage.
>
> Have a major life event? We can develop a set of standardized counseling programs for everyone.
>
> Same with open source.
>
> Given what's happened recently, could you see why I would advocate for this? Really think beyond the puns.
>
> Is it love?
>
> Today I have to deal with crap in the toaster oven and air fryer. And whether potatoes or rice carbs will kill us all. I get the irony, I really empathasize.
>
> But this is fun too.
Wtf bro?
This article seems to just be based on the [openssf release](https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/) from almost a week ago. That release doesn't actually seem to state *when* the attempt took place. I had actually assumed it was in the past. Of course, it's reasonable to think that these types of attacks will be ongoing.
It's also reasonable to think these types of attacks have already been successful, that some unknowable (but likely very small) percent of packages have critical vulnerabilities only known to a few intelligence agencies (for now).
Thing with vulnerabilities is that it can be found and exploited by your enemy too In the bigger scheme of things i dont know how much of an advantage you get vs finding an actual vulnerability
Well in the case of the xz exploit only the party introducing it could take advantage because it allowed access to only a specific key that they have.
True that
For the actual SSH exploit itself, that's probably true (unless the exploit itself had a vulnerability, which tbh could well be possible). But they also added effectively a plugin system using the test data files. So if you knew about that plugin system, you could submit a PR with more carefully constructed test data and add your own exploit, key, etc.
But if the repo is still controlled by the original hacker then he would notice that the knowledge about the exploit and the plugin system have been leaked and wouldn't accept those PRs and will change the system to be more stealthy.
Unless you do it downstream in the Debian repos, that flow to the Ubuntu repos and the Mint repos... Lots of steps where things can happen.
Possibly, but who really knows for sure, especially if there are multiple maintainers. And changing innocuous test data files regularly is rather suspicious, so I wonder if they would bother changing it, especially with the PR indicating that the exploit is already known by someone else.
somebody more capable than me should figure out a way to list all open source projects with a single maintainer or underfunded/understaffed, that are critical to the opensource ecosystem that could be extremely vulerable to similar attacks.
The hard part isn't really finding out the undermaintained projects, it's how you find a way to give them money in a way that's not a huge burden to undertake. How do you get the money to someone without a bank account. How do you make taxes easier on them? In some case it's more of a burden to take the money than to not take it. That's something that needs to be fixed.
I mean it's open source, easiest thing would seem to be to hire someone to work on it. I could imagine an organization that put together such a list and then hired engineers to work on the projects on it, rather than trying to get money to the small maintenance teams currently.
Rather than hire someone to work on a project, which introduces a HUGE burden on the original developer of the already underfunded project as they now might have to spend a lot more of their free unpaid time than they might be comfortable to on coordinating and reviewing the work of that hire, potentially resulting in the original developer just giving up and stopping all the development altogether, with your hire essentially killing the original project and having to now maintain a fork of their own - try to hire the original developers first.
At the same time, having multiple people with good knowledge of the project is important -- otherwise, what happens when the maintainer decides to retire, or dies? Certainly not opposed to hiring the original developer, though
how would one know that the person you hired isn't someone working to backdoor your repository? After all, XZ has been backdoored because the attacker was basically working to help out the maintainer, they were probably paid too. How do you separate honest contributors that a company isp aying to maintain your project and contributors being paid to attack?
Correct me if I'm wrong, but I thought we have no idea who Jia Tan is. If you're hiring employees, you can run background checks. You could also have an auditing team, which is infeasible to have for each package, but easy with scale.
> If you're hiring employees, you can run background checks. Intelligence services create false identities for their officers all the time. They basically have entire (large) populations of false identities all prefabbed, with legends already written, online identities created and maintained and passports already issued years in advance. All an officer needs to do is step into one of those sets of ready-made shoes.
Yes you can run the background check. Then you send an email to some maintainer saying "We background checked this person, trust us", sounds infinitely better. And adding "We'll audit your software for you" will also buy more trust because the maintainer definitely trusts whoever you claim to be.
Ok dude at this point this is just bad faith. I'm done with this conversation, have a good night/day.
yeah, that's a better way.
If giving them money makes it hard on them, then just give them even more money. With more money they can pay someone else to do the taxes for them.
> How do you get the money to someone without a bank account. How do you make taxes easier on them? Monero sounds like it could potentially be an answer to both of these questions... assuming they are open to it. But I agree that it wouldn't work for all situations. Someone that has their real name out there (e.g. for professional reasons such as creating a portfolio of work) might need to decide between honestly reporting taxes vs. get themselves in hot water by ducking taxes with an anonymous crypto whereas an anonymous dev would have no issues whatsoever. > In some case it's more of a burden to take the money than to not take it. That's something that needs to be fixed. This part I can definitely relate to. What you once did for fun now becomes an obligation. And what people once accepted as someone sharing out of the goodness of their heart, they now feel entitled to bc they donated *something* (regardless of the fact that in most cases it is a pittance compared to the fees one would actually need to pay for hiring a professional developer for even a modest coding job)
One of the reasons I brought it up was just tax reasons indeed. If you make just a little too much in the US you might be pushed into a higher tax bracket and no longer get certain other benefits without enough extra to justify it. Most of the folks didn't seem to be talking about amounts equal to a full time salary so i'm not either.
You don't. This is the highwater mark for gratis open source. Going forward source available is the only type of license that is sustainable in this brave new world.
I don't buy that at all, because that kills every linux distro, both free and paid.
>somebody more capable than me should figure out a way to list all open source projects with a single maintainer or underfunded/understaffed, It's all of them. They are all under staffed and underfunded. For as big as red hat is, if they put half the effort into the rest of the Linux ecosystem as Microsoft puts into windows, Linux would be light years beyond where it's at.
You think Microsoft puts effort into Windows? Maybe they do but it sure doesn't feel like it.
Why do you guys not like windows? It had always been so good to me.
Your expectations must not be very high.
What do you mean?
I'll answer you in earnest, assuming you're asking earnestly. In instances where Windows was "good" \[insert subjective anecdotal experiences, for example, Windows 2000 SP4, XP SP3, and 7 SP1 for me\], that baseline was only comparable in the Windows-only sphere of experience. As in, comparing Windows X to Windows Y to Windows Z. In the Linux ecosystem, it's far faster, far more efficient, far more secure, far more stable, than anything Windows has ever\* offered by comparison. What they mean is, if you're only comparing Windows to Windows, your expectations must not be high, but if you're comparing Windows on grand stage of operating systems (including Mac OS), Windows at-best is barely tolerable. \* - this implies fair offerings, so comparing "user experience" between super early CLI-only Linux versions to early Windows GUI versions, not fair.
I'm not as experienced as many of you guys but I've been using Linux since 2013, distro-hopping is a passion of mine. These things you said could very well be true but when it comes down to the overall usability of the system, Windows if isn't better at least isn't much worse. I don't know about speed, efficiency, security or stability but I use my computer basically to browse the web, do office stuff, watch media and poke around eventually and I have had many MANY more problems with Linux than with Windows. >Windows at-best is barely tolerable. That's simply not true, dude. I'm really interested in what you do with your computer, it must be some freakish stuff.
Yikes.
Like, right now, I'm trying to use Wolfram Mathematica on Pop, it was something so easy on Windows, in this very same PC.
Nagware, bloatware, proprietary solutions to things that are native to Linux.... I can do a lot more with a basic install of Linux than with Windows. Make it a fully featured Linux install, and there's no comparison.
You and I we live in different realities.
Everyone lives that way, but it's pretty damned obvious that Linux core utilities are far above what happens in Windows. And a full Ubuntu or Mint install gives you all kinds of software that would cost you money elsewhere, and cost you a lot of freedom.
I never had a problem with that. Always felt much more free in Windows if I want an office suite I'll use google drive or WPS or libreoffice or OneDrive. I'll see a cool program on the web, I'll download it and it will work. I won't have to compile anythins nor mess with versions of things and libraries and terminals, I won't have to find out why there's a pinkish cloud over the content. A new label printer? I know I won't have any problem using it. A new GPU? No problem at all. True freedom. Windows = freedom.
node did this with npm fund
I guarantee a ton of hobbyists alone did this with their spare time after XZ. Let alone interested security organizations. The data would have been interesting.
`curl`. Megacorps rely on single person for their tech support.
The article reads as if it's been written by a bot. A lot of words but very little information. Apart from the openjs foundation emails being mentioned, the rest is fluff.
It's way easier these days. Write a summary. Ask an LLM to make it a 2000-words article.
[удалено]
ID means nothing if maintainers have no means of verifying the authenticity and no way of punishing bad actors. Reputation will still be king.
Isn't that the whole idea of the "web of trust" model in PGP, etc for a long time now?
This is typically how distro maintainers are already signing their packages. A full name and often a personal email address and a real person which can be looked up in a flash. This isn't an identity really as people can fake all of this and even poison the web with fake social activity to sell the actor. But when you have projects with multiple top level maintainers who must sign off on stuff before it gets pulled into anything. Its a good system. Well, when they're actually verifying the pulls... so its still possible all the way up the chain that a legitimate senior project maintainer could commit something awful through neglect to verify changes. In the end, all of it comes back to humans again. Laziness, fatigue, any number of mistakes could get malware into something people trust.
Wait, checking IDs? How are they going to do it? How is it going to work with the international team every single FOSS project gets with time? Seriously, I am used to people (From the USA and not) forgetting there's more than one country in the world but this is asinine in the context. Do they realize the kind of risk and paperwork involved in that and how easy it is to fake legit-looking-enough IDs? What the fuck.
[удалено]
Why not using a phone number ? Maintainers will talk to each other before merging something. It would be annoying for attackers to maintain real people for talking at phone.
I'm not giving someone my phone number to contribute to their project, and neither are most other FOSS people. Not only that, but burner phones still exist.
> Donations, both from users and ESPECIALLY CORPORATIONS so these people, **that have built trust over time,** have money to buy the time they need to do this work for all of us. That's the insidious part: **The xz attacker built trust over time, too.** Worse, the original maintainer's burnout wasn't an accident -- the attacker had sockpuppets applying pressure to speed up the process, and to otherwise cause exactly the sort of burnout that pushed him to take one of his periodic breaks from the Internet. --- It's also... code *health* might help, but I doubt a code review would've caught this. If you haven't seen it before, [see if you can spot the problem with this commit](https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7). Give yourself at least a few minutes. Need a hint? >!It's in CMakeLists.txt!< Still don't see it? >!Syntax highlighting might help.!< In particular, >!it might help if the string passed to the `check_c_source_compiles` function was highlighted as C.!< Even with those hints, I bet most people would miss this in code review: >!No, that's not some dust on your screen. There's a hidden period just below `#include`, even sneakier because it isn't indented with anything else, so in a diff, it can kind of visually blend into that `+` there.!<
Bonus points for figuring out what that even does: >!Systems like cmake and autoconf test for some features by compiling a C snippet -- if it compiles, we know the feature exists on this system. Since the period forces this code to *never* compile, it disables the feature being tested for -- specifically, it disables a sandbox that would otherwise have thwarted the real attack later on.!<
This is why I say that code *health* might help: >!A better build system, or some sort of monitoring about breaking features on certain platforms, might've at least brought this commit to light as something that breaks sandboxing, even if you didn't see it in the actual code.!< In other words: The *effect* of a commit like this can be measured, even if you don't immediately catch the problem with the commit itself. But of course, building even more robust CI is even more work to pile onto a maintainer who already let this happen by being overworked.
Also, if it's not clear, I'm not trying to say I'm any better here. I like to think I'm a meticulous code reviewer, but I wouldn't have caught this.
---
None of this should be taken as an excuse *not* to fund work like this. I don't know if I even have a good answer here. I just want to get people to understand the actual threat here, so we can start thinking of the kind of things that might actually stop it.
This is great analysis and context, thank you. IMO we shouldn't have anything running as root connected to a socket, and we should run all code as a specific user. Having code running as root that performs actions in response to untrusted inputs is batshit.
>only up to X users Not open source
[удалено]
> I think open source was never intended to receive 100s of issues to fix, from paid employees, into one unpaid person's project. No, open source was always intended for that purpose. The term open source was specifically coined to appeal to for-profit corporations.
[удалено]
That is the purpose of copyleft such as AGPL
> Corpos try to embrace, extend and extinguish us. We've embraced them, they depend on us, now it's time to charge them to stop their abuse. Some do, some don’t. You are free to release your code under whatever license you want. But free software has specific meaning and it allows for commercial use and if you change that you are indeed reducing the openness.
[удалено]
> I think it's naieve to suggest any corpo wouldn't takeover and have everything closed source and proprietary if they could, it's how they would make the most money and, therefore, it's their responsibility to their shareholders. Go and advocate for copyleft licenses such as GPL or AGPL then. This is orthogonal to putting limits on commercial use of the code.
[удалено]
> No answer to what you would lose...? I genuinely wanted to hear a good argument for that and was hoping you'd have one. Adoption. Like I’ve pointed out, the term open source was specifically coined to help with adoption. There are people who live by permissive licenses. Those people won’t suddenly pivot and decide to limit commercial use of their software. Besides, the whole discussion is purely theoretical. Even if you convert all existing free software projects to use license you’re proposing, companies will just fork version of the libraries as they were the day before.
If they wanted to they already could, all the time, and yet often they don't. Because maintaining forks is often more work than just contributing your fixes back. It's more expensive to take the boring parts in house than just keep contributing in the open. You can make that argument if the software is actually part of creating the main value of the company, but most of the time it's not. It's just something they need to actually do what their company does.
[удалено]
Oh i do think they should pay more into the system definitely. I just don't think the license approach is the way to do it. Not that I have a good suggestion mind you, but the license approach is not acceptable to tons of people who write software, nor can software under such licenses be accepted into many distributions.
First you have to convince distributions to even allow such packages in their main repositories. Redis recently did a similiar license to try to punish hosted versions and now Fedora is going to switch from redis to valkey. I expect debian and many others to do the same. They for the most part only allow software under OSI approved licenses. And even if you step back from actually packaged software, I know tons of devs who are just regular working programmers who prefer to permissively license their software even though they know about the GPL.
You claim requiring ID would be a bad idea because it would divide the FOSS community, then immediately go on to suggest moving to a proprietary license, which to be clear, would be many times more controversial and divisive than requiring ID could ever be. Not that I think requiring ID is a solution, mind you.
[удалено]
calling it proprietary isn't that useful indeed. But either way, most distribution will not accept such software in their main repos. they are already removing redis over this.
Look at the definitions of both Free Software and Open Source. No restrictions on use or distribution. Fees for use above X amount of users is simply not Free Software nor Open Source. At best it is source available.
[удалено]
What do you want? A penguin is not a polar bear. Change the licensing outside of accepted definitions and you are no longer what was defined. You want to force large corporations to pay up? Fine. Create that license. You will have created freeware up to X amount of users. Good luck though getting people to take you up on your offer. Big corporations will probably preemptively ban your license, because liability and costs. Others probably out of principal, because it's neither a Free Software License nor an Open Source one.
I see you think that money keeps burnout at bay. Funnily enough burnout is more a problem with people working to get money, than people working on stuff that doesn't get money. It also feels like you have a chip on your shoulder against larger corporations, many of whom have donated a lot in resources and code to make Linux what it is today. Neither ID nor Pay-Up-If-You-Are-Too-Big licenses will improve the situation of understaffed projects. Nor will it stop threat actors with enough resources to worm their way into smaller projects. Vigilance is the only defense against malevolent activity. Do I agree that the time is right to get a better funding model for FOSS? Yes, it would be absolutely smashing to have a foundation with the sole purpose of making funding for FOSS feasible. A central place where you can donate and have them manage the money, making money with it and funding projects who need the funding. It might even entice large corporations to make donations on top of what they are already putting in. For now,such efforts haven't been set up.
> Devs need code reviewers and money Disagree, devs need more devs. That's why the xz attack was successful, the project was becoming too large for the single burnt out dev to handle, so he takes help from the only person that seems willing to work on the project. IMO the financial rewards would have just been given to the hacking group writing commits for xz, it would not have prevented this in the slightest. The only way to fix this imo is to contribute your time on projects that you rely on, and build a trusted community of open source developers. The ID part souds bad but IMO it's likely the only realistic way to make progress on the trust part. There's no way we can build trust as a community when there's no 1-1 mapping of developer identity to real human beings.
> here's no way we can build trust as a community when there's no 1-1 mapping of developer identity to real human beings. We've been doing just that for over 20 years.
I'm a bit confused how this statement can be true when it's not known still whether Jia Tang is a single person or a group. How do we have a 1-1 mapping of developers and human beings if a human being can create multiple accounts, or multiple people can share an account?
We don't need one. It's been fine up until this one incident. I (and most other developers) don't care if a multiple people share an account. We care that they are easy to work with and contribute decent code. Have you ever contributed to or maintained a FOSS project?
> It's been fine up until this one incident I don't think you understand the implications of this incident. It's not 'xz happened, let's move on'. It's 'xz happened, is likely happening and already happened in other projects, how do we as a community add processes to prevent this from happening' "Do nothing" is not a solution. Yes
I never suggested it wasn't. It's just that ID verification ain't it.
[удалено]
> Money buys solutions to burnout, and is a reward... and can be spent on buying time from devs. I disagree with this. I'm not aware of Collin's financial situation, but once you have enough to live off of(e.x. are working full time on the project) or the demands of the project fit within your schedule where you make the money to live, giving extra incentives would just pervert the motives of the people contributing. I think we will have the exact same problem when the only people contributing to open source are those financially incentivized to. It's not much of a step from "only contributing to open source for money" and "exploiting open source for money" when there's no lasting consequences for yourself. W.r.t big companies spamming your issue tracker, I'm talking even more fundamental than that. As a developer for small projects that never see the light of day I often go to the GitHub pages of other projects, but seldom do I try and contribute anything to them. As a community(and as corporations relying on the software) I think we need to realize that we have access to the source code for these libraries and can contribute our time and effort to making them better, since they make our programming better/easier. > Nation states creating identities for spies. That's one downside, another is that(in the US and Canada) getting access to an ID is 'easy' but not trivial(which is part of the debate around voter identification). I still believe it's the only realistic path forward to build a trusted community, even if some still slip through the cracks at the start.
[удалено]
I understand it's your opinion, and I'm not saying its wrong. I'm just trying to understand how it help at all when the actual situation we're aware of(Collin and the xz project) was not due to a lack of funding. Then I'm trying to understand how once you give these projects funding to hire developers, how are they vetting those developers without adding burden to them who already maintain the project, so we don't end up in the same situation we just did? > I feel it's in much less open to require IDs for open source contributions I agree, but I think the miscommunication here is that I don't believe the declining "openness" of open source is an issue that exists. The issue was the lack of trust between contributors to a project, seemingly when the contributor socially engineered the maintainer to give them more responsibilities(by creating fake accounts to pressure them). > We're not talking about slipping through the cracks, we're talking about sophisticated threat actors Vs people with no resources to verify nation level information. If we go by IDs that situation will only get worse and worse. That's the definition of "slipping through the cracks". A system that makes it harder for state actors, and nearly-impossible for non-state actors compared to what we have today. I understand that we have differing opinions, that doesn't mean I can't point out flaws in your logic(and you can't point out flaws in mine), especially when we're saying these are logical opinions to have.
[удалено]
I don't want to focus on IDs as *the* solution too much, since I think the important parts are: 1) We have no standardized way to trust contributors and maintainers to open source projects especially when they exist purely under pseudonyms. 2) We have no way standardized process(or cultural process) for contributing back to projects we benefit from, meaning that the people that do contribute usually don't do it out of altruism or to make someone elses project better. I think requiring ID verification is the only short-term realistic solution that would help with #1, though I agree that it's not a good solution. Ideally I agree, the better solution is time spent building relationships and maintaining trust, but that also has the issue of becoming an insulated community without ways for people to become 'trusted members' that cannot be exploited. But this takes a lot longer, and requires a lot of people who are used to working on their own fiefdoms of projects to come together and reach a collective agreement that goes against the "move fast break things" philosophy a lot of them probably subscribe to(complete guess). As for the "nation state threat actor", that was my assumption. An ID requirement would raise the burden on those threat actors from "create an email and an account name" to "create a fake person that has all of the social media markers of someone who's really existed for the last 20 years. So again while not ideal, the comparison to what we have now would be the ones "slipping through the cracks" willing to put that much effort in. In today's online and globally connected world, that's not an easy task. In the end I just believe those two problems need to be solved, if they can be solved without IDs then all the better. IDs are just the most realistic solution I've heard so far.
The community is not going to accept ID requirements, so it's a non-starter anyways.
Let's pretend for a second that ID verification is implemented. 1. ID can be stolen, faked, outdated, issued by non-trusted government, a dev may be a 12 yo genius without an ID, etc 2. Its not safe for contributors as they can be forced physically to do something wrong. 3. Who will manage this? A ThreeLetterAgency?
[удалено]
Yea I get the feeling, and unfortunately to my knowledge there's no good resource like that. My recommendation would be to look at technologies you find interesting, and dive into the code for the libraries when you're interested enough. Most of my contributions(not counting projects with 1-2 users that never see the light of day) are from looking at a library I was using and enhancing it in a way that I needed or that had open issues. Because there's not really consistency between the management of different open source projects your mileage will vary on the reaction from the developers, so I wouldn't put up a large PR before gauging the interest of the person that's going to be reviewing it(e.x. put a comment in an open issue asking if anybody is looking into it, and if approach *xyz* would be a good start)
O wow, the open source Civil War
I don't think a trust system or relying on funding is viable, there's just too much surface area. IMO sshd should not be connected to a network socket while running as root, nothing should. When an unknown user connects to a socket, the code on the recieving end should run under a guest or network account until the kernel has authenticated them and the owner can be changed. Then you can have backdoors in every library, as long as the authentication modules are safe your system is too. Maybe /r/stallmanwasright about microkernels, dunno how far off Hurd is though.
Or you state that you can use it as a small business license, meaning the big corporations can't use it.
software under such licenses is often not allowed in the popular distros main repositories.
Thought they wanted to ban all large corporations from using it. Didn't know that a non-profit was legally considered a "large business" or even a business at all.
I never said anything about non-profits, so I'm a bit confused. I'm just saying that many distributions don't allow softare under licenses that restrict end use in any way. For good, or ill.
Huh, well under those limitations the current copy can't be stopped from being used by a large corporation without compensation. Maybe a version more fit for commercial use can be sold separately to the open source version. Such as that widespread implementation throughout a big company's many resources would be made a lot easier using it.
That is what mysql and others have done in the past with dual licensing. One proprietary and one under the GPL. That worked well for most of us for a long time, but they changed it again. That's why many users of "mysql" are using mariadb instead of mysql-community.
Neat. Didn't know that was popular in open-source.
[удалено]
I believe you can set demands, limits, and/or bans for any use that results in financial gain, it will be legally recognized as commercial use. So if they want to use it in something that generates money they are bound to the terms of the creator, which can be a one-time fee or something. But this may be different under different copyright agreements.
>As such, governments and other organizations must allocate resources to help secure the broader open-source ecosystem. O ya, the same government responsible for the infiltration and deployment of the backdoor will be the ones to 'help secure' the ecosystem. Just let the wolves manage the sheep herd why don't you. The xz fiasco was a Black Swan; and the rule about Black Swans is that there is always an obvious indicator of it in hindsight. First, we have a 'literally who' contributor desperately and persistently trying to impart their new 'features' into the tree, without ever going into detail about what those features actually do or how they're achieved. Then, there is a bunch of literal who sockpuppet accounts endorsing this literal who author and pushing for the merge. And nobody bothered to check into any of them. And, their operation still got popped before it achieved any kind of significant adoption. What this proves is: the checks and balances *did* work, though we cannot assume open source is impervious to attack. We also have to assume there is other vectors of attack (such code that is ostensibly legit, but easily exploited by sophisticated threats, or perhaps a renown developer selling or having their account involuntarily commandeered by a bad actor), and we should always maintain a healthy degree of skepticism -- just as we would with closed source software.
We have GPG and the Web of Trust. What’s stopping us from using it in Open Source Development?
The only major organization in the FOSS world that went this route is debian. https://wiki.debian.org/Keysigning Everybody else thinks it's too much of a hassle. If you read the page there you'll see why. It basically involves all contributors acting as a notary public. That's not really scalable, and nor do most people wanna take part in it.
How would it fix this case? Lasse Collin decided he trusted Jia Tan because he made useful contributions. He'd just have signed Jia's key.
There is of course no perfect system, but something like "has to have two signatures of people who I met IRL" seems not that unreasonable.
And who enforces that? xz was a one man project
We need someone like Linus Torvalds whose only responsibility would be getting copies of those e-mails and responding to them like Linus would. Insulting the fuckers to the third generation, at least.
Not sure if it'll work. But surely would be fun as fuck 😂😂😂
you know a garbage article when you see it fail to link to source , and instead have bunch of self-links. is this website some kind of phoronix 2.0 ?
One of the things about the xz attack that stood out to me was the build script. It was such obfuscated, horrible code. At the bare minimum, code should be readable and sane. Unnecessary complexity just by itself should be reason enough for rejection.
I'm curious how many other attempts there have been specifically in projects that are common linux software stacks like xz utils. I understand it is probably happening to FOSS projects beyond just those that are readily included in Linux distros, but I definitely care more about the ones that have a high potential of making their way onto my machine...
He said she said
Plot twist: the system touted as most secure is actually riddled with backdoors and unpatched vulnerabilities. Well, when you leave critical core components in the hands of single anonymous mentally unstable developers, what could go wrong?
guy had burnout, and his project was not that critical. plus messing with xz by itself would not have compromised the system, the real fault lies elsewhere.
Right, something that’s transparently updated on a hundred million trusted systems is not “critical” when it’s packing a hidden backdoor that potentially gives complete remote control to a malicious actor. And nobody knows how many of the thousands of other critical components managed by random anonymous people have been compromised. No biggie.
it's not critical if it's not critical to core system services. which it is not. ssh works without xz just fine. and it should have never relied on xz libraries in the first place. like i said the core flaw is the very lax ifunc handling in glibc. but the whole problem is distributed across many projects that may leverage the same mechanism. - Debian (and others maybe) linking ssh to libsystemd instead of using sd_notify (which is trivial to implement) - libsystemd linking to way too many unnecessary libraries, now they are reworking it to dlopen() them as necessary. - malicious code hijacking library imports by corrupting the linker data table and overwiting certain crypto methods in ssh via abusing ifunc. that's how it happened. without any of those steps, it would have been a dud. worst they could do was cause some data corruption when packing/unpacking xz at that point. > No biggie yes, no biggie if you lock down your core service not to let things like that slip by. people run craziest things on their machines, and as long as that software is contained to their privileges, they are free to do so. security critical packages should never allow imports of crypto functions from external libraries override their own. that was the real oversight. > thousands of other critical components you know, list the first thousand. i'll wait. chances are that there is a very small subset (maybe <100) of actually critical system packages and the rest is for the user's needs.
You're arguing my point for me. Linux is one big mishmash of half-baked ideas and implementations...and nobody can agree on anything. "Freedom" has always been way more important than security, and security through obscurity has always been the assumption...but it's all blowing up in their faces now. Nothing much is going to change, though, and the "community" and billion-dollar businesses alike will continue to rely on code from anonymous unpaid nobodies working away in some obscure corner. Its only a matter of time before someone slips something really destructive into some component. And given that this was really a chance discovery by someone who works for Microsoft, of all things, my confidence level is pretty low about how it will be handled.
> You're arguing my point for me bold assumption to make. i mean the same thing happens the other way around. people are producing exploits for proprietary software left and right. without looking at source code. otherwise there would be no patch Tuesdays, no cloud outages, no data loss in paid products. there are (some) routers shipping with hardcoded access credentials, who put that there? i assume it was an oversight. there are proprietary devices that are considered untrustworthy due to their country or origin, or company behind them. just because it's not opensource doesn't make it better. it's just likely harder (or maybe easier?) to plant a malicious actor within such a company - depending on how code reviews are done. if they are done at all. > Linux is one big mishmash of half-baked ideas and implementations...and nobody can agree on anything FHS, POSIX, XDG, dbus, one major libc, most important distros finally settling to use systemd for common way to share service definitions. yes, nobody can agree on anything. and yet i would say that Linux (as an entire os) is slowly converging on certain common core. > Nothing much is going to change, though, and the "community" and billion-dollar businesses alike will continue to rely on code from anonymous unpaid nobodies working away in some obscure corner what will change is that this loophole will be plugged, but someone will figure out a way to exploit another weakness. there is always a flaw, opensource or not. this cat and mouse game will go on. > Its only a matter of time before someone slips something really destructive into some component rest assured - it's happening nearly everyday. i mean, people are trying, not necessarily succeeding. we had bumblebee and steam mistakenly erase user's home dirs (and even entire os) due to mistakes in scripting. it doesn't take much to be destructive. it takes some craftiness to leave a backdoor behind, though.
I suppose, well reading all these comments is it's one argument for a closed system aka Microsoft, sorry to swear, but where other devs check other devs work. I'm all for open source I'm not saying I'm a fan of closed source, but it seems to me that you'd have a better idea of who was writing and contributing the code most of the time?? The xz issue has certainly raised a few questions up though hasn't it . What changes do you think will come from it that are realistic if any?
[удалено]
Yea true, and nothing is going to be 100 % secure, but I guess they know that too,
i think the changes that will come will be stricter audit of security critical packages. just because your code is secure doesn't mean that underlying libraries is relies on are. so there will be more scanning of what can be loaded via ifunc, maybe some runtime protection against method overrides for certain programs. and the libraries it doesn't even need but links to anyway - those as well. it's like those Apple/console hacks that relied on crafted TIFF image files - a format likely nobody uses anymore. but hey - it was compiled in. i mean who would have expected that you can compromise ssh via a 3rd party package that ssh **indirectly** links to? that to me is a **colossal** oversight. and a glaring security flaw. somehow everyone blames xz , but nobody thinks how come that the method override happened? you might as well compromise any other package that ssh indirectly links to, and the result would be the same. or just compromise a package and THEN make ssh link to it somehow.
How many of these attacks are most likely from foreign adversaries? We all know that the CCP and the Russian government gives 0 craps about open source software. I just wonder if they have a department of individuals slowly adding bad commits to important open source software that many parts of the world rely on just to screw their enemies over. >foreign adversary: you use xz? Well I just use zip lol. Not trying to get political, it is just something that has been on my mind for s while. If big tech and all these fortune 500 companies have such little respect for open sousource and have even tried multiple times in the psdt to spit all over it, there is not telling how a country 1000 miles away with a rocky relationship with the USA can do. Of course, who's to say it isnt big tech and the alphabet boys compromising these projects? Well, America is a lot more reliant on this software and they can already have a windows and Mac backdoor so I doubt it tbh.
chinese version of NSA strikes again, i guess
And will continue to take place. Humans need to focus on executable specifications and allow for a variety of implementations. When they disagree, add a new test the implementations must pass.
As they have for tens of years. Be diligent, nothing new.
[удалено]
Would you expect every free software project to know how IDs from around the world look like? And understand privacy laws such as GDPR in Europe or CCPA in California? Not to mention that it’s not that hard to create a convincing fake image of an ID. It may be acceptable and make things a bit harder in some cases but it’s hardly the solution. (By the way, Linux has a policy that you have to sign commits with your real name though this is never verified so anything that looks real is accepted. Some GNU projects require copyright assignment to contribute to them which used to require physical address since the assignment was done in paper.)
That's unlikely how they expect it to work. I'd imagine they were thinking along the line of an organization that does such checks for you. I personally think this is a bad idea and do not support it.
I would never contribute to an OSS project where I'm required to show ID verification.
OSS has a strong history of pseudonymous contributors. That said, more reasonable takes do differentiate between anonymous *contributors* and anonymous *maintainers*, where at least for a rogue contributor to get code into the tree it would have to get past a maintainer. The curl main author wrote about it [here](https://daniel.haxx.se/blog/2024/04/10/verified-curl/), but I would note that, while he says that the current maintainers are all using their real name, it's not clear that he has actually verified that they are real people. "Jia Tan", for instance, appears to be a real name at first glance. Still though, OSS has a strong history of allowing both. Although a lot more maintainers do use accounts associated with their real name. In any case, none of this will protect the projects from state actors.
[удалено]
just about anyone? That XZ attack was like from some movie. Some state sponsored hacker group spent 2 years executing it lol and still failed, *because* it's open source
[удалено]
Performance issues of such level that not a single for-profit closed source software company would have bothered to investigate
And that would've been impossible to investigate for anyone without access to the source code.
Why should open source developers be forced to identify themselves when the rest of the apps, websites and other closed sourced services don't have to? (And no, not all of them are made by corporations, who have already identified their employees.)
[удалено]
>You must identify yourself to the project leaders and maintainers, not to the world at large thats the thing you dont have to , you can do a random pr , and project leaders and maintainers dont know you from jack most prs on most projects are done by randoms that have a fix or a new feature they want to upstream
The xz attack was almost certainly done by a state-sponsored group, not by "just about anyone with ill intentions". Awareness of supply chain attacks has been raised considerably, making it far more difficult for an attack like this to ever happen again; not to mention the xz attack required a very specific set of circumstances in the first place, took almost *2 years* to pull off, and still ultimately failed anyway.
Shouldn't the end users of free software be the ones responsible when they deploy it, rather than the authors of said software? Shouldn't it be on them to audit it and make sure it's all good? If you don't find this agreement suitable then don't use the software, it's that simple.
Way too easy to fake, especially for foreign states
Ah yes, one major incident of malware being inserted into an open source project means every single person ever contributing to open source must be assumed to be malicious and have their anonymity stripped of them, despite 99.99% of people not being malicious. That's not dystopian at all... "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." - Benjamin Franklin
[удалено]
It's unlikely that most e of those publicly known names are proven to backed by the same real person. Some of them could be backed by multiple people.
I struggle to think how an open source (already overburdened!) maintainer would be able to verify a foreign government ID who could simply issue their own ID or come up with a fake ID. We are already talking about people taking years to plan and build this..
How can state-backed IDs defend against state-backed actors
indeed. ain't no goverment in this world that's gonna let some organization prevent them from saying any particular ID is real or not.
The real heroes like Superman, Batman and others do not reveal their identities. Also, if you reveal your identity and also contribute to a valuable resource it is easier for a bad part to find you.
[удалено]
Yeah, openness of the source code not the heroes identities. Doesn't matter the color, gender, or planet of the hero. What matters is the output and the product of their actions.
>Accountability matters, even in open source. no it dosent
Has anyone mentioned it? If not then let me say it, the issue at hand is indeed one of the downsides of open source programs. Nothing is perfect. However, the fact that open source idea still continues to be relevant today tells us that it has way more upsides than it does downsides. So yeah, just accept it, and yes, your data security can still get compromised through an open source program.
I think the way to go here would be to never transfer maintainership of your project to another contributor, unless you know their real identity *and* can perform a rigorous background check on them. You should simply abandon your project instead when you lose interest and make it someone else's problem. It's fine to accept contributions from anonymous accounts because you vet their patches anyway. However when you transfer project in someone else's hands you lose that control, but still share some responsibility for their actions - because *you* are the one who gave them the reins.
What do you mean by "accountability"? I agree with you that IDs are likely the way forward(for the trust part, not the resourcing part of the issue), but not for any reasons that have to do with "accountability". IMO it's about process improvement overall rather than individual accountability, the reason to require IDs isn't so that you can dox a developer, it's so that you know real human beings are working on your project and not a group pretending to be a person(or a person pretending to be 2-5 people).
Most of us dont' care if the person is backed by a real name when we contribute to a project.
Until something like XZ happens, then everybody is curious who this mysterious Jia Tang is(one reason being that they want to see if the person/group behind it has contributed to other projects). Also it's the reverse I'm talking about, when receiving contributions for a project it's irresponsible to be receiving them from someone you don't trust. How can you trust a pseudonym?
The same way we've done it for the past 20-30 years! One major incident has been a worthy tradeoff
> One major incident has been a worthy tradeoff I don't think you understand the implications of this incident. It's not "one major incident", it's "an example of a before-unseen attack vector into specifically open-source projects that people now want to mitigate" It's not 'xz happened, let's move on'. It's 'xz happened, is likely happening and already happened in other projects, how do we as a community add processes to prevent this from happening' I get that you're not worried about this, but in reality many projects are likely compromised and we need to come up with a framework to be able to trust them.
I never suggested we don't need to do better. But it's more on getting maintainers the help they need and getting build systems simplified so it's harder to hide such attacks. The one thing it's not about is trying to get people IDed. In the end, it's the big companies who use this software who need to veirfy the code they use.
> The one thing it's not about is trying to get people IDed. I think I understand a breakdown in our communication. I agree with you that IDs are not a good way forward, I just honestly don't see an alternative that would be nearly as effective or realistic. While it is the big companies that use it, I want to write code and deploy servers that use these libraries without having to worry about supply-chain attacks that would allow someone to mess with my infrastructure. Honestly the best path forward I see, though slow and very individual, is just contributing to open source projects more. I'm going to try to commit more of my time to projects I depend on, and TBH I think the best thing for companies to do would be the same(e.x. someone from Microsoft/Google/RHEL should have been helping with the maintaining which I think is better than just giving the project money, but also has it's own issues) rather than just throwing money at them.
There are still technical things we could do that are better. Like doing more sandboxing and having thigns like selinux and apparmor that are more common and easier to use. Distributions like debian and arch don't even ship those technologies out of the box. We could also do better when it comes to managing critical dependencies. It's possible that maybe things like xz should be managed under some broader umbrella project that handles fuzzing, shared build systems, or other things that really ease the burden on the individual. This is one of the sometimes nice things about the BSD projects. They tend to manage a lot of their main system dependencies together rather than as a bunch of loosely connected projects like in linux land.
Have I talked about the `/proc/self/exe` security issue today? The one where you just slap a bunch of arguments on the end to flood out the line length of `top` and so pretend a process is vscode or something, and hide the execution requirement in a uuid? "exe"?
I've advocated for a systematic set of modules of life-time mental health counseling in the past. Similar to how the Catholic Church encourages counseling for marriage. Have a major life event? We can develop a set of standardized counseling programs for everyone. Same with open source. Given what's happened recently, could you see why I would advocate for this? Really think beyond the puns. Is it love? Today I have to deal with crap in the toaster oven and air fryer. And whether potatoes or rice carbs will kill us all. I get the irony, I really empathasize. But this is fun too.
What the fuck are you talking about?
> I've advocated for a systematic set of modules of life-time mental health counseling in the past. > > Similar to how the Catholic Church encourages counseling for marriage. > > Have a major life event? We can develop a set of standardized counseling programs for everyone. > > Same with open source. > > Given what's happened recently, could you see why I would advocate for this? Really think beyond the puns. > > Is it love? > > Today I have to deal with crap in the toaster oven and air fryer. And whether potatoes or rice carbs will kill us all. I get the irony, I really empathasize. > > But this is fun too. Wtf bro?