I think Jonathan Blow has been implementing all these backdoors recently just to prove his point.

This person clearly has no experience of open source software development. I gave up a few minutes in, after I realised it was full of outdated tropes that were common in the early 2000s. Even the likes of Microsoft now work on open source projects and use them within Windows. It would be nice to think that software would be safe from attack if everyone just used a proprietary development model, but the situation is far from that simple. Actual software development varies greatly between projects, whether proprietary or open source. The difference with open source is you're operating in an environment where what you're doing can be observed. It is the difference between working in a room with the blinds drawn and one with them raised. A project being open source does not mean it has no QA. Equally, a project being proprietary does not mean it has great QA. But, with open source, it is likely you can determine, to some extent, what QA is being done by observing what tests are checked into the public repositories and what bugs are filed. Both the Heartbleed and xz attacks are indicative of a social problem. Our systems are built on a stack of programs from various sources and both issues derived from a program that many others relied on being essentially the work of a small group of developers. Following the Heartbleed vulnerability, there was a push for greater support for such fundamental projects, but here we are a decade later with the xz attack showing that hasn't come to fruition. The biggest takeaway from the xz attack is not anything about the code itself, but the way a person was able to contribute to various communities over a period of a couple of years; see boehs.org/node/everything-i-know-about-the-xz-backdoor#2022 It is only with hindsight and knowledge of the backdoor that it is clear what all their changes were leading to. Many of them are still innocuous as far as can be discerned. This person would likely not have gained as much power over the project if it hadn't essentially rested on the shoulders of one person who could not keep up with development and had mental health issues. We need to support our developers better. There's no reason someone couldn't entwine themselves in a proprietary software development company. They are hardly going to show up at a job interview and tell you they plan to backdoor your project. The reason we know so much about the xz exploit is because it was all done publicly. It's just a pity there were no more eyes on these developments at the time and one person had so much control. Had the same thing happened in a proprietary company, the person would have been fired and it would never have been known about publicly unless the compromise went into a released project and was spotted by an external party. The xz issue was spotted before it could become more widespread by people external to the xz project using the code and observing odd behaviour.

the Einstein parallel was a good point too

a typical comment from Jonathan: a rational and reasonable fact is blown into some world-changing-paradigm-shifting tangent. "An additional layer of QA in a real company" lol, like Intels and Facebooks don't work on Linux! That additional layer of QA is probably why Skype asks me to install "an additional admin tool" every other day. Spy works is a real thing since forever, in all walks of life. It is indeed in the interest of the free world civilization to maintain its principles in all walks of life. By the way, it includes the propaganda in mass media. Cold war was not about spy works, it was about propaganda, it was a war of world views. And what alumni of US universities believe in now: that communism is good or bad, that capitalism is moral or immoral? That shows clearly the failure of the US spy agencies, who can spend full-paid years focused on some little temporary battle, trying to undermine some open source stuff to get even more redundant info on some weak adversaries, which will not be actionable, all the while they lose the whole way of life of their surroundings.

damn, he saw the future

Voice clone of Donald Trump 😮

Proving that knowledge is the best way to see the future.

7:27 to all the naysayers.

you feel experience in his voice.

Came here to pay homage to the prophet

BlowGODS....

I don't see it all about the vetting, etc. Those doing their job, their vetting is influenced by stress, etc. A lot of open source projects are passion projects and care more about the resulting code than the developers at commercial companies. What is a problem: accepting code from random persons, all with their own motivations, on the Internet probably requires a higher level of vetting then within the same company. But if you are Microsoft... that also goes out of the window(s).

less than a min, 50 seconds to be precise, into the video the man has summarized xz backdoor

He's right but I don't see how this is an argument against open source specifically. It is an argument against bad software development practices.

My man Jon being a prophet once again.

DUDE did this age well (see "Linux got wrecked by non-consensual backdoor attack")

The man was right, XZ was backdoored 😂😢

Your intro statement is so apt and relatable to what happened with xz fiasco. When there are 100+ countries with cyber int units waiting to hack each other for superior cyber advantage , projects run by an incentive to contribute to project as a hobby investing tons of time is less appealing . Well it did happen with liblzma poisoning (xz). Preconditions so specific , targeting indirect dependencies ( Openssh -> lib systemd -> tainted liblzma ) , anti debugger conditions , in addition to other specific conditions, all this in addition to gaining trust of original maintainer by making ‘good’ contributions over an year , adding conditions to prevent fuzzing to OpenSSF months before introducing backdoor, speaks volume about the resources available with these nation sponsored threat actors . if not for performance issues on sshd, this issue would not have been detected. Kudos to dev for finding this one, we got extremely lucky with this one. 🤦‍♂️

Really accurate

i was here

huh , that call was correct afterall

I've said it before and I'll say it again. Comparing a tiny open source project without much oversight to Windows is ridiculous and is like comparing apples to oranges. Compare the LINUX KERNEL to WINDOWS and then we're talking. The Linux kernel has tons of oversight (Microsoft, Google, Meta, AMD, Intel etc all contribute to it, have maintainers from those companies and is used extensively by these companies). With Windows the security team is actually shrinking as Microsoft is focused on their most profitable businesses like cloud/Azure and AI so it's quite easy to get hired if you're competent and introduce a backdoor.

xz-utils backdoor says “Hello”

I'm coming back to this again because of the xz exploit in ssh lol

lzma moment

How well this has aged with the liblzma backdoor injection that just got found. Crazy

Vindicated with XZ's recent backdoor.

This starts out early being a bad take, because Open source and package managers have already existed for 10+ years and it's only gotten more popular. To say that "it won't last long" is to not be able to see the forest for the trees. Are there potential security concerns? Sure, but all software has security concerns, I'm not convinced that open source is some how more dangerous than other software, especially if it's being actively maintained and scrutinized.

jonathan bad on blow jobs

Ah the good old Blow, I forgot how big his ego was. He's kinda not lying tho, OSS can have problems, good luck finding zerodays in OSS with many lines (even on Closed Source tho), nobody got times for that except people with malicious intent. But hey... Crypto AG existed, so Closed Source or Companies are not so safe, because it's more opaque, I kinda understand the argument "we can see the code"... but like he said, too many lines and you ar e more susceptible to malicious injection in OSS. Still interesting to listen to the guy.

The hardware back door situation mirrors the Microsoft situation that JB explained. In CPU companies, there are a lot of people cross checking everyone's work and more so for security stuff. I design hardware security stuff in CPUs you use and I've spent years identifying the back doors in specs (NIST, ISO mostly) and working around them. It's my head on the line if my logic is insecure and I'm fully aware of the forces trying to undermine hardware security. The motherboards and BIOS code are an easier entry point for government hackers. It's easier to pay off a few people in a factory to replace a network transceiver chip with your own. Security problems in CPUs are hardly new and have come around through traditional hacking methods rather than back door insertion and the vulnerabilities exist in the first place because of a necessary trade off between execution speed and side channel resistance. The danger in closed source whether for HW or SW is that with closed source, is that there is limited energy in the company for others to help you. Top tip, happening right now for people designing stuff to specs - try and find a constant time BCH error correction implementation in a secure sketch construct. Critical for your security, but no one sells a constant time BCH - it's unobtanium. So you need to design around that if you're in that position that you have to design it. HW security is hard work.

Surely it would be easier for governments to just direct companies within their nations to develop software back doors. The issue with FOSS is literally any researcher can just go and look at the source code and test it for bugs. Whereas if say Microsoft was directed to implement such a feature you have the devs involved and the upper management as a point of failure.

easier said than done

He does raise some good points. So really the solution is to reduce surface area and create paradigms that are designed to be secure if it truly is something so important.

And then the Twitter Files were released proving Jon correct regarding fed infiltration in tech companies

first he says: 'how do you think that's not a thing?' without providing any reason to doubt serious maintainers who review all those check-ins of code YET he still asserts that: 'i guarantee you that there are at least 17 serious exploits in linux kernel'. He might be right, but i don't like that he is so sure about some arbitrary unfounded things, yet so skeptical about some others.

I really like how this ends with a counter-example. Great show of good-faith

so what? you wana say close source software makes more sense to use? ah, sorry. you are creating games and all of them are close sourced :)

"Most servers are linux" complete bullshit

7:27

well, we can fall into the Ken Thomson Backdoor problem, very interesting topic. Also don't forget that Intel shipped a running working copy of Minix in the Management Engine running on ring 3. So the exploits and backdoors are everywhere, even beyond our reach.

JB is simply wrong here, and it's sad to see someone with such capability and insight in other respects fall for such naivety. A thought should be followed to its eventual *final* conclusion, not just the next logical one. 'Expense' means absolutely fsckin' nothing for a state actor when it comes to deliberately orchestrating the insertion of code to further facilitate the exfiltration of data, the future exploitation of a software system, etc. Inserting an 'agent' or whatever to a corporation for whatever purpose is purely a tertiary concern for a governing agency which presides over the soil on which a corporation conducts its primary operations. The corporation will always have a financial motive first -- not the concerns of the general populous -- and thus is easily bought off through any of a number of options. Simple preferential treatment for an upcoming contract auction is often adequate enough to buy oversight over many smaller corporations and the bigger ones aren't much more difficult. Conversely, hiring, training, monitoring, and deploying assets to introduce complicated security flaws into OSS projects in the hopes that the bugs will go unnoticed by many millions of others in a community for an adequate period of time and ensuring that they remain able to make changes to safeguard those flaws in the event that other code is introduced which inhibits the facilitation of them is decidedly more expensive over time. You can pay a corporation to overlook something in a private codebase, or even just dictate that they engineer something in a specific manner to maintain compatibility with self-designed platform restrictions -- and you don't even need to explain your reasons -- and they will gladly make those accommodations so as to guarantee the financially-beneficial relationship. You cannot, however, exercise that kind of influence over a continuously fluctuating populous in a diverse and complex group of communities, especially as other agencies are apt to do the exact same thing. The bottom-line here is that it will always be easier, more efficient, and overall more effective to influence private codebases than public ones. OSS is not, by any means, impervious to malevolent meddling, but it will always be 'never worse' than private codebases. The acquisition & privatization of many major OSS projects proves this point pretty effectively.

'PromoSM'

With closed source, the government can just tell them to insert the black box in their code and not tell anyone, with open source they have to sneak it in. I feel like it could be larger issue with closed source than with open source.

Yeah, people will try, but they will often fail, at least with projects like Linux. Linus is very strict on what pr's he includes, and there is a lot people (at least for large active projects) that work on, and look at the code.

With closed-source you don't even need to review or ask anybody. You as an NSA shitter show up with a warrant and put whatever backoors into Windows that you want. I prefer having 1% chance of discovering a zero-day with my own eyes to 0% when using proprietary software

This is because MBAs are just book npcs

Company spending massive money on security is a joke. Was working in few big IT companies as developer and even QA/Automation engineer. The careless approach for vulnerabilities is staggering. Some were as simple to fix as changing headers configuration in the server. When applied I was mailed/contacted by higher management this is not possible as application will not work. After suggesting that in that case we would have to redesign/rewrite piece of app, I was told no budget/resources/time for that. After time I stopped to care about it. There were assigning jr resources to fix vulnerabilities (maybe 2 resources at max), where all people with experienced were formed in teams of 8 or more to work on ADA/WCAG issues as this is "vital" for the business.

I love being an IC. No pressure, less meetings and fake friendships

And that is why we get crap software at large tech firms and good software at startups!