Social engineering takeovers of open source projects | Hacker News Reader

Social engineering takeovers of open source projects

openssf.org

822 pointsmooreds361 comments

I'm a maintainer (one of many) of an open source project, and this topic has been on my mind a lot lately as I review PRs.

I am more suspicious of PRs from new contributors by default now. Of course I keep these suspicions to myself, but besides simply reviewing code for all the regular things, I now ask myself "what sort of sneaky thing could they be doing that appears benign on the surface?"

It's not the new contributors you have to watch, it's the sleeper contributor who has built up a solid reputation and then is "activated". At least that's how I understand XZ.

It’s both. The fact that one happened recently does not preclude the other.

"Trusted account for sale"

That's great that you are considering this more now.

But the xy story taught us, that every contributor is dangerous, the most dangerous ones are probably the most helpful and most skilled contributors. If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor.

Another thing that was not talked about a lot: There are many ways to compromise existing maintainers. Compromising people is the core competency of intelligence, happens all the time, and most cases probably never come to public knowledge.

One follow up to compromising existing maintainers: This makes the creators or long-term good faith maintainers maybe even more "dangerous" than new maintainers.

Are we facing a Byzantine generals kind of situation now?

We have always faced it, it’s just that there's more awareness of the potential issues.

>If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor.

Unforuntately it's easy to sandbag being dumb. Just because someone submits a PR defining constants for 0-999 does not mean they're actually bad at programming.

Sure, but being known for submitting bad code is going to make code reviews more thorough, not less. It's drawing additional attention to yourself.

> defining constants for 0-999

That person might just be an old school Java <5 developer.

That person might just be a regular Java developer who works on a project which onboarded Checkstyle, and can't disable it's MagicNumber check.

https://checkstyle.sourceforge.io/checks/coding/magicnumber....

Man, I hate such tools. Do I run into problems when I try to convert seconds to minutes?

Larger problem than magic numbers ever could be.

Yes! Anytime you see a function signature like "int timeout", it's safe to assume that the unit is in femtoseconds and pass a gigantic number while you curse out the incompetence of the developer. Either name your variables correctly (timeoutZeptoseconds), or use a proper data type (like a Duration or Period in Java, TimeSpan in C#, or a user-defined literal in C++).

Oh, now I get why you need those constants:

  var secondsPerWeek = Math.pow(2, SEVEN) * Math.pow(THREE, THREE) * Math.pow(FIVE, 2) * SEVEN

How incredibly wasteful.

You can form most useful numbers with just ten singe-digit constants, some casting, and string concatenation.

Indeed, in python you can just eval.

> Compromising people is the core competency of intelligence, happens all the time, and most cases probably never come to public knowledge.

Yea. It would almost be strange if security service didnt consider the route of getting "kompromat" on a developer to make them "help" them.

They would be really bad at their job, if they didn't try.

Developers would be really bad at their newly expanded job, if they didn't resist.

The most secure systems are those that are also resistant to rubber hose cryptography.

"Rubber Hose Cryptography" comes in the form of a PR.

"Rubber Hose Cryptanalysis" comes in the back door and waits for you in the dark.

No, it 'comes in the form of' a rubber hose...

> consider the route of getting "kompromat" on a developer to make them "help" them

I suppose that’s an option, but it also introduces an additional risk of exposure for your operation as it doesn’t always work and makes it much more complicated to manage even when it does work.

Does it matter though? They don’t have to say “I am so and so of the Egyptian intelligence service and would like to blackmail you”

They might not even use blackmail, they might just "help out" in a difficult financial situation. Some people are in severe debt, have a gambling problem, are addicted to expensive drugs, or might need a lot of money for a sick relative. There are many possibilities.

The trick is finding the people that can be compromised.

> They might not even use blackmail, they might just "help out"

If the target knows or suspects what you’re asking them to do is nefarious then you still run the same risks that they talk before your operation is complete. It’s still far less risky to avoid tipping anyone else off and just slip a trusted asset into a project.

I think you're going overboard on what's required. Take anybody who is simultaneously offered a substantial monetary incentive (let's say 4 years of total current/vesting comp), and also threatened with the release of something that we'll say is little more than moderately embarrassing. And this dev is being asked to do something that stands basically 0 risks of consequences/exposure for himself due to plausible deniability.

For instance, this is the heartbleed bug: "memcpy(bp, pl, payload);". You're copying (horrible naming conventions) payload bytes from pl to bp, without ensuring that the size of pl is >= payload, so an attacker can trivially get random bytes from memory. Somehow nobody caught one of the most blatant overflow vulnerabilities, even though memcpy calls are likely one of the very first places you'd check for this exact issue. Many people think it was intentional because of this, but obviously there's zero evidence, because it's basically impossible for evidence for this to exist. And so accordingly there were also 0 direct consequences, besides being in the spotlight for a few minutes and have a bunch of people ask him how it felt to be responsible for such a huge exploit. "It was a simple programming mistake" ad infinitum.

So, in this context - who's going to say no? If any group, criminal or national, wanted to corrupt people - I really don't think it'd be hard at all. Mixing the carrot and the stick really changes the dynamics vs a basic blackmail thing where it's exclusively a personal loss (and with no guarantee that the criminal won't come back in 3 months to do it again). To me, the fact we've basically never had anybody come forward claiming they were a victim of such an effort means that no agency (or criminal organization) anywhere has ever tried this, or that it works essentially 100% of the time.

This doesn't look intentional at all, because this is basically like how 90% of memory disclosure bugs look

Absolutely. And that's the point I'm making here. It is essentially impossible to discern between an exploit injected due to malice, and one injected due to incompetence. It reminds one of the CIA's 'simple sabotage field manual' in this regard. [1] Many of the suggestions look basically like a synopses of Dilbert sketches, written about 50 years before Dilbert, because they all happen, completely naturally, at essentially any organization. The manual itself even refers to its suggestions as "purposeful stupidity." You're basically exploiting Hanlon's Razor.

[1] - https://www.openculture.com/2015/12/simple-sabotage-field-ma...

Nobody can tell if they are intentional or accidental.

I suppose the point is that even though any given instance of an error like this is overwhelmingly likely to be an innocent mistake, there is some significant probability that one or two such instances were introduced deliberately with plausible deniability. Although this amounts to little more than the claim that "sneaky people might be doing shady things, for all we know", which is true in most walks of life.

> “I am so and so of the Egyptian intelligence service and would like to blackmail you”

No, but practically by definition the target has to know they’re being forced to “help” and therefore know someone is targeting the project. Some percentage of the time the target comes clean about whatever compromising information was gathered about them, which then potentially alerts the project to the fact they’re being targeted. When it does work you have to keep their mouth shut long enough for your operation to succeed which might mean they have an unfortunate accident, which introduces more risks, or you have to monitor them for the duration which ties up resources. It’s way simpler just to insert a trusted asset into a project.

I would guess there are many projects they could target at any given time.

The more projects they target the more risk of being flagged and preventive measures to be engaged by counter intelligence etc.

I’m reading all this with sadness realizing that one of the Internet’s last remaining high trust spaces is being destroyed.

> one of the Internet’s last remaining high trust spaces is being destroyed

One of the Internet's last remaining high trust spaces is being attacked.

What happens next is still unwritten.

From what I know of today's developer culture the solution will be for one company, probably Microsoft given their ownership of GitHub, to step in and become undisputed king and single point of failure for all open source development. Developers will say this is great and will happily invite this, with security people repeating mantras about how securing things is "hard" and "Microsoft has more security personnel than we do." Then MS will own the whole ecosystem. Anyone objecting will be called old or a paranoid nut. "This is how we do things now."

As an positive counterexample, US recently reduced federal funding for the program which manages CVEs [1]. There was/is risk of CVE data becoming pay-for-play, but OSS developers have also pushed for decentralization [2]. A recent announcement is moving in the right direction, https://medium.com/@cve_program/new-cve-record-format-enable...

  The CVE Board is proud to announce that the CVE Program has evolved its record format to enhance automation capabilities and data enrichment. This format, utilized by CVE Services, facilitates the reservation of CVE IDs and the inclusion of data elements like CVSS, CWE, CPE, and other data into the CVE Record at the time of issuing a security advisory. This means the authoritative source (within their CNA scope) of vulnerability information — those closest to the products themselves — can accurately report enriched data to CVE directly and contribute more substantially to the vulnerability management process.

> solution will be for one company, probably Microsoft given their ownership of GitHub, to step in and become undisputed king and single point of failure for all open source development.

A single vendor solution would be unacceptable to peer competitors who also depend on open-source software. A single-foundation (like LF) solution would also be sub-optimal, but at least it would be multi-vendor. Long term, we'll need a decentralized protocol for collaborative development, perhaps derived from social media protocols which support competing sources of moderation and annotation.

In the meantime, one way to decentralize Github's social features is to use the GH CLI to continually export community content (e.g. issue history) as text that can be committed to a git repository for replication. Supply chain security and identity metadata can be then be layered onto collaboration data.

[1] https://www.darkreading.com/vulnerabilities-threats/nist-nee...

[2] https://github.com/yoctoproject/cve-cna-open-letter/blob/mai...

It can be a stepping stone towards a world in which we use sandboxing and (formal) verification to safeguard against cultural degradation. There's no alternative, too many bad actors are roaming about. I hate that as much as the next guy :(

Who can share a threat model with specific probability estimates on this? FWIW, I’m less interested in the particular estimates (priors) and more interested in the structure.

> Another thing that was not talked about a lot: There are many ways to compromise existing maintainers.

Also not talked about a lot - there are many ways to compromise existing software engineers who are paid to work on proprietary software systems.

It is a worthwhile reminder.

But, source-not-available proprietary systems are just totally hopeless from this point of view, of course an intelligence agency could slip something on. A bored developer at the company could too. Users of this sort of proprietary system have just chosen to have 100% faith for some incomprehensible reason.

I don't think that's relevant to this discussion though, as open- and closed-source subversion would seem to follow really different paths.

- Open-source subversion has the big advantage of having the code, testing and build processes in the open which allows for the attack surface to be exhaustively studied, whereas closed source requires code exfil, reverse engineering, inside intel on processes etc.

- Closed-source subversion can hide in other places -- binaries can be corrupted on a compromised server etc. Seeking to influence the code-based development seems like the hardest road IMO.

- Open-source maintenance (at least the kind under discussion here) stops at the maintainer, whereas most corporate dev is in a hierarchy with non-uniform commit authority. None of the same social techniques would apply.

> If someone barely get's a PR accepted, they probably lack the skills to add a sophisticated backdoor.

That's true, but it's also true that a sophisticated and well formed PR is probably genuine too. Hostile PRs are the exception rather than the rule. And if only the high quality PRs are treated with suspicion, then the attackers will tailor their approach to mimic novices. General vigilance is required, but failure is likely because these attacks are so rare that maintainers will grow weary of being paranoid about a threat they've never seen in years of suspicion and let their guard down.

Early this year, I've received a hostile PR for a "maintenance only" JavaScript authentication library with less than 100 stars but which is actively used by my employer.

It added a "kinda useful but not really needed" feature and removed an unrelated line of code, thereby introducing a minor security vulnerability.

My suspicion is that these low quality PRs are similar to the intentional typos in spam emails: Identify projects/ maintainers who are sloppy/ gullible enough and start getting a foot in the door.

Looking at some of these cases, each PR on their own doesn’t look suspicious, but it was what they all built up to — in some cases from multiple bad actor contributors that, on the surface, weren’t connected.

Wasn't a key thing of the xz attack vector that people where encouraged to download the custom source release instead of the autogenerated Github one? I don't know if that is a pattern but it seems like best practices in the (source) supply-chain could prevent a large class of these attacks.

yep.

same with npm. i publish releases of my OSS libs to npm, but there's no guarantee that what is uploaded is what you see on github. that's a lot of trust you have to put into my opsec, etc. not good.

That is unfortunately how `the `autotools` ecosystem works; although I guess projects could guide their users to run `autoreconf -i` if working with the source code instead of the release tarballs before doing the usual `./configure && make && make install` step.

Can't you just commit the configure file?

the attitude remindes me of maintaining game-servers and looking out for cheaters; once we had a handful of folks looking out for cheaters, it turned the community against itself calling everybody a cheater... i think it is good to be cautious; but overall it's the same cat and mouse game we've seen before. i can only say good luck on not letting it stress you out second guessing other folks actions and intent - and hope we continue writing code for humans to read vs the cryptic, obstrufcated, even "elegant" code (not to dive into the skill issue rabbit hole lol)

I’m in it for a free t-shirt.

https://medium.com/pentesternepal/hacking-dutch-government-f...

what do you look for to prevent this?

Why is there not a policy that any PR can be rewritten by a maintainer ? Wherever the PR looks a bit odd, rewrite it so do the same thing a different way. Enough unpredictable change to disrupt finely-tuned subterfuge.

you can wait for tree (or x) PR's passing specified unit tests for functionality and then merge a random one. But this is a luxury (effort wise) for any kind of project.

This is what I feared the most. Trust issues that lead to less progress and a community that slowly drowns in suspicions. When the XZ thing happened they were already going after one person accusing them of being part of the whole thing in one of the bug reports on github.

Honestly, a good PR should have a very clear description of the idea and a sample implementation, and then a trusted core contributor re-implements the fix on his own. But Github users are entitled and spoiled by Github-marketed commercial software, so they will rage at this.

Sounds like you're describing an issue, not a PR.

An issue usually doesn’t have the code for implementation of the solution. Yes, very often patches are attached in comments, but they are not required and usually attached by other people, not the author.

This should be the mindset for any commit. I mean, they could add something benign unknowingly. Something could hack their account, or abuse a flaw in your commit-system to appear as someone else. They could have a melt-down, or strange ideas and adding something for nonsical reasons. Shit can happen all the time from all directions for any reason.

Consider this comment: "But the xy story taught us, that every contributor is dangerous, the most dangerous ones are probably the most helpful and most skilled contributors."

What is "xy"?

It's tempting to classify this as a typo but y is a long way from z on the keyboard, while the x and z keys are adjacent.

I type xz on a regular basis because it is so often used in place of gz for compressing tarballs. I cannot imagine calling it "xy" unless I rarely used it.

It’s not the new contributors, but older ones that might have already built a rapport with you so you are less critical in your review. That what happened at Xz utility and the hacker nearly got access to every Linux machine out there.

First I think that it is wrong to single out this issue on Open Source projects.

For example, since the first versions of app stores, when you are an app developer you would receive a lot of messages from random shady dudes ready to buy your application if it had a few users.

Also, the xz thing was kind of pretty smart, but it is also a thing in mind of most OSs developers that you can't trust any random contributor and so that you will be very careful of really knowing someone before giving some privilege.

Just look how the debian policies were designed or that things like "pull requests" were invented for Open Source projects where everyone in a project used to be allowed to push whatever in private ones before.

Chrome extensions have also been subject to those purchase offers for a long time.

The scope of impact if a mobile app becomes malicious is _immensely_ smaller than if xz becomes malicious. The latter seems to be national security level

Only because most people aren't using mobile apps for real work. But if someone were using a mobile app to perform SSH and the app is backdoored, it's game over for any server you SSH into.

We've been adding features for 30+ years to open source software, they become so complex only very few people understand them anymore. Recently I looked into jfet level 2 implementation in ngspice, expecting familiar equations, but through series of small changes and maybe some DRY too, the code is almost unrecognizable. When graybeards finally retire, there will be lots of shrugs.

Your average American could quit working for 5 million dollars. They could live comfortably for the rest of their lives off that money, if well invested (read EFT for sp500)

5 million bucks is change for you average government.

"Amazon made billions on my project and if I turn a blind eye to this I can retire, fuck them..."

Sponsorship, for good or bad makes a lot of decisions simple.

Probably wouldn't even need 5 Million. According the the PBS article about the 2 US Navy sailors arrested for spying around august of last year one of them was apparently only bribed $10k-15K for the year [1]. I was pretty shocked at first but it made sense that with the financial stress many face in today's market a 10K bribe would go along way and have a high return on investment especially if the potential payoff for a backdoor or zero-day is in the millions [2]

[1] https://www.pbs.org/newshour/politics/2-u-s-navy-sailors-arr...

[2] https://en.wikipedia.org/wiki/Market_for_zero-day_exploits

Even politicians are cheap these days.

It astonishes me that for less than the price of a nice car, what people seem to be able to do.

After Abscam in the late 1970s/early 1980s, one of the quote going expressed surprise not that politicians could be bought, but that they were so cheap.

I cannot find that quote now.

>2 US Navy sailors arrested for spying around august of last year one of them was apparently only bribed $10k-15K for the year

This is exactly why investigations for security clearances focus mostly on a person's financial situation: someone who has a lot of debt and shows a pattern of poor financial management, i.e. someone who'd jump at a chance to make an extra measly $10k, is the kind of person they want to avoid giving a high security clearance to, because of incidents exactly like this.

It's a common misconception that clearance holders who sell secrets make a lot of money doing so, and this just isn't the case: it's comparatively small amounts like this. For someone who's deep in debt and desperate, it doesn't take much to buy them.

Money isn't the motivator I worry about. Money requires people to make rational decisions about what they think they can get away with.

Threatening someone's family? Who wouldn't be willing to turn their access to a project into a hack that has some possible theoretical future harm to protect their child?

Sure, the circumstances to being able to leverage someone like this are rare, but the population which is susceptible is much larger than those willing to do somethibg similar for just money.

I've been working on thanks.dev for over two years now & reading this report is disappointing to say the least. Why not spend the time to explain the value XZ Utils created for all the commercial users & what companies can do to better supporting maintainers with hundreds of issues experiencing burnout from their unpaid work? OpenSSF should instead promote FOSS programs like https://frontendmasters.com/blog/how-were-supporting-open-so... & how they help their open source community stay active. Working in open source is a social contract & corporates need to be better citizens if they want to reduce their risk profile.

On first reading your comment makes a lot of sense, and is certainly logical for maximizing the common good.

But unfortunately, companies simply don't work the way you are proposing.

The short reason is this "good citizenship is indistinguishable from corruption. Therefore good company governance leans away from both."

The somewhat longer answer is that while a "company" might have a lot of money, or might make a lot of money leveraging some common good, it is not (usually) one person's money.

The bigger the company the harder it gets to actually -spend- the money. There are procurement departments, various sign-offs and so on. First and foremost it helps if there is a tangible (defendable) reason to spend the money.

Yes, companies "give" money away. Usually under the guise of marketing. It's easy to donate money to the local cancer center. It's harder to explain the marketing value of supporting random open source projects.

For tech companies it's -somewhat- easier, but even then it's simpler to donate time rather than money.

I've said it a lot lately, but OSS development has to "commercialize" if it wants to be commercial. That means first understanding "what companies pay for" and designing products to fit that.

Or target individuals with excess cash of their own that they're willing to just "pass along".

"What companies pay for" is anything they cannot get for free. If the value of an OSS project is mostly in its code, then any license that allows it to be used commercially will mean lots of free-riding.

Companies want to have their cake and eat too: the code is free, but they're complaining there's no warranty.

If companies want better guarantees, then they should contribute more.

Thing is, they still continue using the code even as they are complaining. Which is to say, they'd very much like the warranty so long as it's also free, but if it's not, they're willing to go without.

I'm sorry but this is a huge copout. At least the big companies and governments have the money to solve all these problems. They have literally teams of lawyers on retainer and they can hire a few more people for all the other self created bureaucracy. None of the things mentioned here are laws, of nature or otherwise.

I'm not sure what you are proposing. You declare cop-out, but then fail to describe a mechanism.

Who exactly would initiate this change? Shareholders? Board members? C-suite? Employees?

What do you propose an initiator should argue to convince colleagues? Why should an initiator spend political capital on this rather than on themselves?

Of course they have the money to give to random OSS projects for no return. What your post lacks is any motivation for doing so.

> Shareholders? Board members? C-suite?

Yup these three. Its been too long that we give passes to executives for their bad behavior. If a company is using a tool they should be thinking about paying back. If they are not, they are being bad members of society (and yes companies also live in a society). It is not hard if there were good people in charge. Who's only lookout isn't to make the share price go up every quarter.

Anyone who has played Eve Online is familiar with this process. Gain membership, become a valued contributor to the corp, then betray it for profit.

And one difficulty here I believe is that those intent on social engineering think about it in more sophisticated terms than their targets, which perhaps is obvious.

And part of the process can be a kind of performative incredulity at the very suggestion that they are part of a campaign of hostile takeover, even if it's exactly accurate. I suppose you could even have unfortunate circumstances where parts of an open source community are unwitting advocates of being co-opted.

And I think you probably see a parallel in state-based information warfare, where part of the objective isn't just to spread misinformation, but to shift cultural norms so that the transmission of misinformation is inherently easier, which can involve sewing distrust in institutions or expertise, or normalizing a gish gallop argumentative style.

I'm perhaps stating the obvious here, but I suppose the upshot is that human psychology can be targeted in a programmatic way, and there might need to be something in the way of a normalized infosec-oriented doctrine relating to the stewardship of open source programs as an intentional countermeasure.

>> And I think you probably see a parallel in state-based information warfare, where part of the objective isn't just to spread misinformation, but to shift cultural norms so that the transmission of misinformation is inherently easier, which can involve sewing distrust in institutions or expertise, or normalizing a gish gallop argumentative style.

TikTok springs to mind when reading this...

Not going to quote the whole thing, but yes hard agree. Contrasting this factual opinion with the opinions in the “sell TikTok” hn threads is quite a delta.

My thought immediately went to Linus Torvalds. The way he acted was tolerated in the past, but the culture was changed and it was used to force a change onto the project.

Same thing with all of those Codes of Conduct that suddenly propped up.

Are you saying codes of conduct make the transmission of misinformation is inherently easier, e.g by sewing distrust in institutions or expertise, or normalizing a gish gallop argumentative style? Are you saying Linus Torvald's behaviour prevented those problems?

I think it's more that it leads to brain drain. Be it by misinformation, by discouraging anyone who doesn't fit [demographic of leadership], or by simply not giving proper code reviews in the name of politeness. All 3 ways creep up and the code base suffers from lack of care, and/or lack of talent.

We can certainly debate how effective old methods were (and yes, I have no doubt Torvald's old behavior turned off many a talent) and how we can improve on them, but in a more general viewpoint we need to remember that many open source code bases are, or started as, volunteers providing their knowledge in their free time. It doesn't take much to make them walk to the next repo. Or not contribute to OS at all.

It has not occurred to me before, but I don't see why the cancel culture surrounding such matters couldn't be used as an attack vector. Basically, target key maintainers who are vulnerable to this (white, male, history of questionable interactions etc) and push until you force them out one way or another. Then when project gets in trouble because of the lack of qualified manpower, pitch your own agent as replacement. For bonus points, make it someone who hits the right buttons wrt "diversity".

This is exactly what I was thinking. Thank you for expressing it so much better.

Re: normalization of gish gallop

The speed reading shit they do in competitive debate was in my opinion 100% caused by clandestine elements who wanted to keep the future “revolutionary” intelligentsia class obsessed with ivory tower elitism so that they don’t get too close to doing actually subversive things.

I have no other explanation for how otherwise smart people think that speed reading lacanian psychoanalysis is high school is valuable for anything.

https://en.m.wikipedia.org/wiki/Spreading_(debate)

In Europe, the most popular high school and university debate format is British Parliamentary in which spreading is not popular because you only have 15 minutes to prepare and weakly justified arguments don't require responses.

https://youtu.be/XyIK_Cg_8jc?t=327

British culture certainly has plenty of ivory tower elitism, yet has passed by this. I don't think it's a special revolutionary pedagogy, just a different interpretation of how to deal with subjectivity in debate.

I agree with you that it's incredibly bizarre, but I associate it with the strange cultural norms that can only crop up in very specific academic environments that have just the right alchemy of academic strangeness, competitiveness, and idiosyncratic historical origin. I'll compare it to something I recently discovered, which is some viral video I recently saw of some sort of pig fare where kids lead pigs out on this walk to show how well the pigs are trained and I think to show off the pigs as models specimens, and the kids do this intentional intense eye contact with judges in order to get the judges to look at them. It seems so strange and abnormal, but it was explained away as just something that's part of the history of the competition and having strategic value for being effective in the competition.

I've seen videos of the college debates you're speaking of though, and I've definitely felt that they're badly in need of reforms that either impose a word count or otherwise disincentivize speed reading.

The long and short of that is just to say you can explain it without regarding it as some sort of intentional state disinformation program. I would also say I find that especially implausible just because, while I don't love the practice, I don't think it degrades our ability to follow arguments or have information literacy necessarily, and meanwhile modern social media absolutely does seem to instill habits that reinforce short-term attention spans, disjointed thinking, object permanence problems and the like, all of which would dispose people to be more receptive to bite-size arguments that don't have to fit into a comprehensive or coherent worldview.

To play devil's advocate people seem to be quite attracted to self-sabotaging ideologies, as they offer the intoxicating justifications of "not my fault" and "no point in doing work". Hell, the typical "rebellious" things are practically hand-picked to be ineffectual at gaining any even small sort of power and demonize doing so. Just look at the dynamics of being accused of "selling out".

> And I think you probably see a parallel in state-based information warfare

My own research shows it’s the opposite: they destroy trust in institutions and experts by telling the truth when those groups lie to their own citizens.

The US did this routinely during the Cold War.

More recent examples include:

- demographic facts about murder, violence, and police

- demographic facts about college enrollment, eg the racism at Harvard

- George Floyd’s autopsy report

- images of cities burning; reports of the 70+ people murdered

- facts about COVID

- facts about COVID vaccines

- facts about Ukraine’s status on the battlefield

- footage of Nazis in Ukraine

- facts about Tavistock and WPATH lacking scientific evidence for their recommendations

Because institutions and experts have normalized lying to “nudge” the public via narrative manipulation, it has become easy for adversaries to undermine the nation by showing contrary facts.

People become more radicalized by demonstrating with evidence a supposed ally has betrayed them, eg, your government lying to you. Once broke, trust in institutions and experts takes generations to repair — or a replacement of those institutions entirely.

> transmission of misinformation is inherently easier

This may already be the case, according to "Study: On Twitter, false news travels faster than true stories" (2018):

https://mitsloan.mit.edu/ideas-made-to-matter/study-false-ne...

If anyone has a few hours free, I'd recommend this documentary about Eve Online - https://www.youtube.com/watch?v=BCSeISYcoyI

When you said "a few hours", I was expecting 3, not 6(!)

6 hours of robotic Siri-like voice speech? Torture.

It's a shame because I presume if it's recommended despite that it must be insightful.

Rudi Dutschke's long march through the institutions. Marcuse endorsed it -- because it works.

Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it.

Those changes of maintainers need to be synced to package distribution sites like npm.js or Debian packages and put in context with versions/releases.

In Europe this was introduced for banks after the banking crisis. If a bank does any organizational change, a report is sent out to all member states of the EU right away and any of the 27 national bank agencies can check if they notice something unusual. It might be possible to bribe a few people in your own country, but it’s really hard to bribe all responsible people in 26 other countries.

> Maybe we need a reporting system for maintainer changes of bigger projects. Some list where they get published and people can keep an eye on it.

The rust project does it. There's a repo with all [active] members and their permissions on github, etc. These get synchronized and updated every time there's a change.

This is, in my eyes, one of the most important parts of "Infrastructure as Code". You should make the list of who has what permissions a critical artifact, as immutably part of the repo as any other change.

Just for the main project, or for all/most packages on crates.io?

Every repository and team under rust-lang on github.

That's great, but I think that's not enough. This would need to extend to crates.io, I'm sure there are some packages, that are very commonly used and not part of rust-lang.

The major projects aren't on github.

Could you elaborate?

How about simply paying the maintainers and then getting stuff done like the classical business does.

Well yes, sounds great, but it doesn't really address the security problem. Now you've just got the bad guys getting two paychecks instead of one and the good guys getting one paycheck instead of zero.

> bad guys getting two paychecks instead of one

1 to 2 paychecks = 100% increase.

> good guys getting one paycheck instead of zero

0 to 1 paycheck = infinity increase.

With a known baseline of "good paychecks", financial analytics can pursue identification of "bad paychecks".

One of the biggest risks for companies is securing dormant code, it's perfectly fine for a project to be no longer sexy enough to maintain. Platforms like thanks.dev have already proven how reward & recognition can help promote development in an ecosystem https://www.youtube.com/watch?v=e5FV-AnKPlo&t=1s

Did you mean: instead of trying to become a maintainer to a trusted open source project, how about bad actors simply bribe the existing maintainer to do their bidding? There would be no maintainer changes in that scenario.

Related, the motivation for trying to gain privileged access to open source projects is to leverage the existing trust associated with that project. A different long game that could be played is to create a new project with the intent on backdooring it a few years down the road, after it has gained sufficient trust.

I'm sure some security researcher is doing this, but we could easily create a visualization of "who has contributed over time" and identify transitioning of maintainers automatically just from git.

This might be worth doing and contributing to a site like bestofjs or libraries.io (I don't really use that one though!)

> who has contributed over time

When major security players insist that using GPG is bad, there is no way of knowing if bob@bob.bob is the same account that it was last month or not.

It is not the idea of GPG thats bad. In fact, the idea is great! The implementation of GPG however is quite another thing. Ease of use and user experience are really not that great with GPG. It is difficult to use even for developers. Developers are users too amd so on.

Try uploading a signed package on pypi. Sign it with sequoia instead of GPG if you like.

You'll receive an email asking you to stop uploading signatures.

you can sell/steal keys just as easily as accounts

Ok. Can you get my private key? Feel free to respond to this comment with my private GPG key.

I think guessing a password and getting lucky is much easier.

Is it really though? Cum-ex and cumcum appear to still work great.

Cum-ex is about taxes (and criminal law). It's unrelated to the stability of banks.

While I love open source, this feels to me like something companies need to pay for.

It might be that no open source contributions I've made are things people care about, but I'm not spending one second of my time for free updating databases so multi-billion dollar companies can feel safer.

I recently had a xz moment where the rust zip crate was taken over by a single person and the original crate was completely replaced. I'm still not sure if this was legit or not: https://github.com/zip-rs/zip-old/issues/446

That does look suspicious.

Honestly, from reading this it seems like people blew it _way_ out of proportion. Someone forked the project to make updates because the original maintainer seemed to be not doing much, the original maintainer came back to say that they were correct to ask about maintenance because they didn't expect to do any more work due to health issues and then volunteered to transfer the crate to the person who forked on their own, which the person who forked it accepted.

It's kind of bizarre to me because I don't really understand what mental model could lead to not taking any action earlier than this if the was things turned out is so upsetting. If they were happy to keep using it exactly as is because no updates were needed, why not just pin the dependency to that version exactly (and republish their own fork if they were worried about old versions being "yanked" and not being able to use it for anything new or offline)? If they did expect some form of updates over time, where did they expect them to come from when the existing maintainer felt they were unable to continue given health issues? Any attempt to find some other solution to future ownership would be heavily scrutinized by the exact people who commented on this issue with strong opinions and don't seem to have much empathy for the health issues, which would defeat the entire purpose of trying to take time away from work for their health.

I'm surprised that this needs to be said, expecting people to put in extra work to project you from what happens to their projects when they literally can't keep maintaining them due to health issues will never work, and it's also just an awful way to treat people. If you have serious concerns about how situations like this could be exploited by malicious actors, you should be paying much closer attention to the status of your dependencies and taking actions to insulate yourself from potential fallout long before some like this happens. If you've gotten to this point under the assumption that you can just veto any change in ownership that you don't trust, you're already too late.

This is not a ‘xz moment’, as a sibling comment said, it is norm in open-source.

Someone with more time forked the repo, included the changes that were necessary, build up trust and then this eventually get merged. Now obviously there is no guarantee they will never act up in the future, but this is not different than for the original owner.

Trust is a necessity to open-source reliably functionning, because it in parts makes up for the lack of money, and allow to move fast.

XZ is the exception. And frankly there is not much to do against it.

> Enable two-factor authentication (2FA) or Multifactor Authentication (MFA).

Not on any third party system, where you're locked out forever if you lose your second factor. Fuck that!

Only self-hosted, where you can recover via physical access.

(That should actually be the first advice: host the stuff yourself. People lose control of projects due to hosting them on third party services. Be the guy who can pull the power cord out of the wall.)

yes and no.

i hate 2FA as well, but in the end, even if i loose my access to github i only loose access to my github identity but i don't loose access to my code, so i can live with that.

of course in the light of this discussion losing access to my github identity would be part of the problem, so it's a tradeoff. is it more likely that someone will break into my account and abuse my identity if i don't have 2FA or is it more likely that i loose my second factor and have to rebuild my identity. in the latter case someone else could also pretend to be me, but since the xz debacle both of us would face more scrutiny that my hope still is that i would win.

will the real eMBee please raise their hand?

> if i loose my access to github i only loose access to my github identity but i don't loose access to my code, so i can live with that.

That means that you need to fork your own project, and there is no way to communicate it to the users, since the new account could just be someone pretending to be you.

If there is a security vulnerability, it would remain unfixed forever.

> is it more likely that someone will break into my account and abuse my identity if i don't have 2FA or is it more likely that i loose my second factor and have to rebuild my identity

Since phones are very easy to break, and until very recently there was no way to backup google authenticator, I'd say that losing your 2nd factor was the most likely of the two.

Now if you say that you backup your 2nd factor seed in your password manager, where your password is… congratulations you're doing over-complicated 1 factor authentication!

well, yes, exactly. once i realized that, my reaction was: why thank you github, you just made my one factor auth more complicated for little gain. well, ok, i don't store the otp with the password, so cracking the password became a bit more complicated too. but for example committing code doesn't require otp and my browser has me permanently logged in, so where exactly is the added safety now?

as for the lost identity. a new user could at least share a warning. that user doesn't have to be trusted to get others to be more vigilant and scrutinize the code very carefully as eg was done with XZ once the issue was discovered. imagine an unknown user would have alerted the community that the maintainer account was compromised or locked out. they could have reached out to people who know them to verify their identity and to corroborate the claim. it would be a long and tedious process, but at least any attacker would be prevented from getting any further advantage too.

it could still mean loss off the maintainership and loss of users, but i can also host my projects in multiple places so that only part of my known and verifiable identity can get compromised at once.

in the end it's partly security theater, partly arms race, partly an improvement through raised awareness...

> Not on any third party system, where you're locked out forever if you lose your second factor.

Every two-factor system I've ever seen is actually two-of-three, with an account recovery code that you save elsewhere.

I lost all my two-factor auths when my phone got wrecked, it was annoying to reestablish access to those accounts (and I now use a TOTP client which backs the tokesn up), but it was tedious rather than difficult.

It was not difficult because you actually had the recovery codes. How many people have them?

Also you're supposed to print them. Where? How many people own a printer? If you print them in a shop they can be considered compromised.

The recovery codes I've seen tend to have been 10 8-digit sequences.

If you don't have a printer and care about recovery codes, those are easy enough to transfer manually onto dead-tree material using a stylus-like handheld device that deposits graphite or ink onto the surface it touches.

Except that you need to decipher your own handwriting years after having written it. And you also need to remember where you safely stored it.

When I know it's important to decipher something later, I have a 100% accurate decoding rate on my own handwriting, so that's not a problem. It's not hard to write clearly and carefully. In addition, they give you ten codes to use, so you'd need to make indecipherable errors in all of them. Also, having a safe place to store documents is table stakes for adulthood.

We're talking about software developers, right?

I would hope that when a software dev sees a widget that says "these are your recovery codes, write them down or copy them to a secure location or you may lose access to your account", they do exactly that.

Except for codes which protect my money (which go onto paper, which goes in a safe), I put them in a password vault. TOTP offers protection against getting shoulder-surfed, key logged, or phished, it isn't much protection if Mallory gets access to my entire password vault. YMMV.

> I would hope that when a software dev sees a widget that says "these are your recovery codes, write them down or copy them to a secure location or you may lose access to your account", they do exactly that.

Yes software developers are known for never making any mistake.

> and I now use a TOTP client which backs the tokens up

What are some good options for this? I think my ideal solution would export an encrypted file, a bit like KeePass does on the desktop, but I don't know of many mobile apps for that.

Aegis on Android.

andOTP on Android does encrypted backups. I once recovered by loading a backup in android emulator :)

Thanks! That one looks cool, but apparently is unmaintained: https://github.com/andOTP/andOTP

I use FreeOTP for iOS.

It has two security levels: normal-level security codes will unlock when the phone is unlocked, high-level security codes require a separate unlock to get the code. The former back up to iCloud (E2E encrypted), the latter don't back up.

This is a great write-up.

It's a very serious issue. I don't really know if there is any "one solution." I suspect that each project needs to set its own bar, and that any dependency that falls out of maintenance should be removed as quickly as possible (which was good practice, beforehand, but even more important, now).

[EDITED TO ADD]

I would also think about "scoring" the sensitivity of projects. Things like cryptography and low-level drivers would be highest-rated, while user-space chrome might not be as important.

Scoring framework: https://securityscorecards.dev/

Code: https://github.com/ossf/scorecard

April 2024 ranking of OSS projects by criticality, 100MB CSV: https://commondatastorage.googleapis.com/ossf-criticality-sc...

Thanks!

I have a friend that used to work for a company called “SecurityScorecard.”

Different beast, though. I think the idea was similar.

The scorecard stuff is flawed.

You want to decide if something is secure or insecure but without reading the code. It's never going to have any correlation.

    > This approach bears strong resemblance to the manner in which “Jia Tan” positioned themselves in the XZ/liblzma backdoor.

No, it doesn't. I stopped after read this. Jia's "attack" was near state level actor stuff. A bunch of emails asking/begging for commit access sounds like a 16 year old sending emails from the basement of his parent's house.

> A bunch of emails asking/begging for commit access

This is not what it says. If you're going to argue, argue with the text from the article not a made up reinterpretation.

It's openssf… All of their posts are basically "install our github action, get our scorecard!". Which I personally think is completely useless.

If they want open source maintainers to do boring compliance stuff, they can pay them.

I won't be doing that for free for sure.

Can we, PLEASE, return back to batteries-included first?

While it doesn’t eliminate the threat completely, but I can sleep soundly knowing that I need to vet one party instead of 1000.

+1. My team still favors batteries-included style systems, even if it means missing out on the latest thing all the cool kids on the internet are talking about. For languages, this usually means sticking with the standard library that ships with it along with one or two libraries that augment it (e.g., BOOST for C++). It's not like "batteries included" eliminates the problem - a bad actor can wander in there and cause trouble. It's just a much more controlled environment that often has a process for contributing. I'm not a fan of the move of languages away from rich standard libraries to the "Random Interconnected Pile Of Internet Stuff".

Unfortunately people like me are in the minority it seems, and the "move fast and break stuff" mentality seems to still dominate the open source world even if that phrase has fallen out of favor - the attitude still seems to exist.

in open source you rarely have the cohesion of a full team to NIH all the stuff that you could pull in libraries for...

The swan, the pike, and the crawfish.

IMHO, Open Source is often misunderstood by companies as free code as in cheap, when in fact it should be seen as collaborative code that aims to avoid redundancy, saving companies countless hours of development, research, fixing compatibility issues and so on, due to such collaborative union between all the developers, mainly the maintainer(s), albeit at the cost of sometimes excessively generic non-performing code, and, here we go, albeit at the cost of potential security vulnerabilities that keep requiring an investment that has been largely ignored.

Perhaps companies should take the necessary reversal for the security of their business and create roles within the organization as guys who exclusively and actively revise the code being used, at the same time as internally classifying the integrity of genuine maintainers to ensure that bad guys don't get paychecks from either the company and the community, by showing facts.

It doesn't solve the problem, but I think it should be a generalized procedure, not just something that very few big companies seem to be doing, and one can see it's not enough.

Ironically, most companies ignoring the issue appear to be targets.

Although it did cross my mind that maybe such companies are not just misunderstanding open source as free code as in cheap, but maybe they also consider the security issues and repercussions as cheap; and if this is what is happening, maybe governments across the glove should impose large fines for data leaks and vulnerabilities in their systems, proportional to the company's revenues, proportional as in making them invest in security. in addition to what the article suggest.

I don't know. I'm just thinking loudly, certainly the problem is not easy to solve.

Doesn't have to be a takeover. If I'm a state actor I'll maintain a few projects specifically so I can hide backdoors in them. When/if one gets popular and I decide to backdoor them I'll claim it was a social engineering takeover.

Exactly, pick something that is expensive right now, make it free and people will use it.

Well after the XZ attack, I was thinking how common this can be. Good to know that at least im not the only one and others inside the community are wondering about this. I hope someone is smart or lucky enough to find a solution to at least be able to lessen the impact of these attacks. I still wonder how many more of these are there, and my question is because of these attacks, isn’t open source more prone to these compared to closed sourced software? Usually the argument for open source is because everyone can read the code, its less vulnerable but now because everyone can write the code and have big incentives to do malicious stuff, doesn’t it make open source worse?

The problem is, we don't know. I've seen PRs that could be curious students, or it could be a first try to see if we are paying attention. It's really easy these days to produce a halfway decent looking PR for someone in their first year of uni and my worry is that an increased volume of low to medium quality contributions will lead to maintainer fatigue. Depending on the project, that may be the point where pressure can be applied to share maintainership.

Many open source projects just don't get enough attention for the 'many eyes' benefit of OSS to occur. Many projects are neglected and poorly maintained, with little participation from the users.

I don't think OSS is particularly special though. If a state actor threw cash around they could find folks at many big companies to do their bidding. In my experience, commercial software reviews are susceptible to the same sorts of attacks as those listed in the article("please review my change ASAP because it needs to go into the next release before the deadline!").

I don't know what to do about this. You could subject approved submitters to better background checks. You can improve automated threat detection and code analysis. You can switch to safer-by-default languages that make backdoors and malicious behavior more obvious.

I wonder if the same issue exists in other engineering fields? Has anyone ever bribed an engineer to make a bridge or a water supply less robust?

> Has anyone ever bribed an engineer to make a bridge or a water supply less robust

Of course, this happens all the time, check the consequences of any earthquake in any corrupt country for the more visible examples

Yeah, for sure. I was mainly thinking about, say, a foreign state actor doing the bribing and not just the usual grift/embezzlement/corruption.

Ah, misunderstood, you mean something like a sneaky sabotage? Hm, don't recall any, the payoff seems to be too small and unpredictable? But I think there were cases of "poisoning" the design of some weapons

Good warning for the future... but what about the past? Any thoughts on retroactively looking at behavior for existing OS projects? Seems like an impossible amount of work.

Maybe not so impossible. Start with making a list of projects that are everywhere. Inside every Linux distribution, inside every react/angular/vue/etc project, …

Then check which companies support those projects with active development, and calculate a rating. Are the companies located inside democracies or are they mostly from china or Russia?

It’s probably not that many packages in the end. A few thousand high impact/risk projects probably.

Backdoor attempts won't be that obvious. The xz incident just had a random unaffiliated burner account and nothing of any clear national origin.

I wanted to make a different point. If for example Google or Red Hat were deeply involved within the xz project, there might have been more people reviewing the code. The evil changes to xz were easy to overlook, but not impossible to notice.

Especially the added "accidential" semicolon made me think about probabilities. I think in a code review I would notice that with a probability of 10-20%. So if 10 people would've looked at it, there might have been quite a low chance to get away with it.

Having some high profile companies involved into an open source project the risk score would drop in my opinion, which would highlight the projects that are completely community maintained, and might be more susceptible.

Having such a list might be a security threat by itself though, because attackers would focus on the "low risk" projects first.

One possibility could be a license that requires big companies to dedicate one or more people as maintainers or at least reviewers of a project if they want to get license to use the software.

GPLv4? I doubt this would be a bigger success story than v3 and v2. Permissive licenses won the war against Copyleft a long time ago.

The list you speak of already exists — it is the package registries of Debian/Ubuntu, RHEL, etc.

What about American companies using mainland China developers to drive their (well known) open source projects with crappy code? Who’s to blame?

We’re currently smoking at the gas station and things haven’t blown up yet…

It would be nearly impossible to ignite gasoline or its fumes with a lit cigarette.

I think the only feasible option, due to the shortage of SWE talent, is a combination of automation, tooling and safer languages. We need better threat analysis systems, and we need to rely more on safe-by-default languages that make program behavior more obvious.

As a (mostly former) OSS maintainer, I don't want to be suspicious of any contributors. I want welcome contributors as co-maintainers.

I don't want to gate-keep specific tasks (such as releasing and updating the website) so that I'm the single point of failure.

It's already hard to enough to get people to contribute more than a README typo fix or maybe a single feature that they need themselves, and get them invested into the project as whole.

Somebody please create an alternative for keeping projects secure that's not based on suspicion and gatekeeping.

I've been saying for years, over and over, that we need to focus on simple architecture and improve our coding standards but I keep getting ignored. People keep making software and tools more complex... "Just use TypeScript" they say, "Just use React, with Typescript" then they end up with literally thousands of unnecessary dependencies. The bad guys are laughing at our collective ignorance and naivety.

Now probably the whole industry is compromised. Maybe our entire political system is compromised because of this.

People just had to look for projects with minimal code and dependencies. Precisely the opposite of what they did. These clean projects were starved of attention and opportunities and the overengineered projects were brought to the forefront. Now they are easy targets for bad actors. It's so easy to hide vulnerabilities amongst complexity... And we've chosen complexity.

I suspect that the bad actors aren't merely benefitting from this situation, they're probably actively encouraging it, in GitHub issue discussions, on Reddit, in the comment sections of YouTube videos, here on HN. Maybe I'm paranoid.

I think this is a reasonable assumption for most high exposure projects. There are state actors from all sides who want to inject backdoors into software and they all benefit from complexity.

It could indicate that governments are more focused on offense than defense.

It seems to be a logical consequence of our short term corporate and political mindset. Offense is the best defense, they say... Ok, but not at scale when your opponents also possess the same weapons as you do; then you both end up worse off.

Typescript has zero dependencies.

Yup, that commenter did exactly what he told others not to do, bashed on something without checking if he's right. Typical bashism. Typescript is from a single big vendor with all the tooling.

React is a different story. By itself it's from a single big vendor, but all the tooling is tons of random packages and scripts...

The fact that you don't recognize how TypeScript adds a massive number of dependencies into your project is proof of how deeply entrenched the mindset of unnecessary complexity is.

Let's not even dive into the question of how `tsc` relies external dependencies written by third-parties outside of Microsoft (it definitely does). Let's not even talk about how many people are working on TypeScript and how big of a target it is for foreign state actors. Let's not discuss how easy it would be to introduce vulnerabilities into `tsc` due to how well it can hide them inside its mangled JS output. An even bigger issue is that TypeScript forces you to add a ton of dependencies into your project.

Once you add TypeScript to a project, you are essentially forced to use a bundler on the front end. Also, it forces you to add a lot of special add-ons for whatever front end framework you're using. You need special add-ons for testing, e.g. `ts-jest`, you need additional linting dependencies and you need to import a large amounts of external type definitions. You now need 2 config files instead of 1 (tsconfig.json + package.json)... 2 engines instead of 1 (tsc + node). The code you write is no longer the same as the code that's running in production; you're running a transpiled version with incorrect line numbers... Now you may need a special library to manage client-side errors with source mapping. E.g. you may need to install the `source-map-support` module or other or you might rely on third party services to help figure out the source of production errors. Your trusty older version of `mocha` now may not show the correct line numbers when tests fail; also `mocha` is now too slow for you since TypeScript takes so long to build... So you end up using the far bulkier `Jest` instead (and all of its dependencies).

Most devs these days don't even realize that it's possible (in fact, easier) to build fast front ends without a bundler. Browsers can now pre-load scripts easily and it's way more flexible than bundling. With native Web Components, you don't even need a framework these days, you can achieve similar results as reactivity using the `attributeChangedCallback` inside custom Web Components. Many people have been successful with this approach in production environments; it's far more lightweight and less error-prone than React development. It also makes it feasible to share components between different physical web pages and services since you don't need to load the entire React framework to use those components. You can follow DHH (founder of Ruby on Rails) if you need proof that you don't need a bundler.

Which of the suggested "Steps to help" would have helped prevent the xz infiltration? For a single-maintainer project, adding bureaucracy can only make things worse.

Seems just being aware of it. Doesn’t hurt to have people be more alert. Although that alertness can quickly become fear and anxiety.

Which can eventually evolve into paranoia.

The fix is easy: license your code as AGPL3. Your project is no longer a useful target as corporations will avoid you, and on top of that you get rid of the demands for free tech support.

Win win.

I wonder how the person that was running “xz” is doing. Hope he’s doing okay mentally after being thrown into the spotlight by the shit stain of a person(s) behind the “jia tan” and et al aliases

This is going to become a huge problem with state actors attacking what is basically public infrastructure. We should be publicly funding efforts to protect it.

This is only going to get worse with Large Language Models. Let's imagine a somewhat knowledgeable individual, could craft both emails, messages and even commits with a bunch of prompts. Those will relate deeply to the project.

Do you have any evidence or real examples to support that? I hear people say similar things but see nothing to suggest LLMs are a particular threat.

The real threat of LLMs is their potential to ruin your day if you use them to assist in your work.

Username checks out

Are you asking for evidence that LLM’s can be used to write emails and chat messages?

Maybe one day it will happen, but right now LLM-generated persona would likely set off every alarm bell for a lot of people. LLMs have very recognizable style, and it usually falls right into the uncanny valley.

It doesn't have to be completely automated, just enough to make the process of juggling multiple personas a bit smoother.

The "recognizable style" that people usually refer to is the default persona that most are exposed. However, the style can be changed very drastically with some fairly simple prompting.

I don't think this is going to be a big issue. Those attacks have to be high-profile attacks. If you look at the xz backdoor, there was some top notch engineering behind it.

If we ever reach a level of LLMs being able to do that, we don't need any open source contributors any more. We just tell tell the LLM to program an operating system and it will just do it.

It's a pity they don't give any details about the "attempted takeover" - are they available elsewhere?

I hope there is a better way to maintain open source projects without being overly cautious and suspicious of every PR someone makes. Maintaining open source projects is hard, and this is going to slow down development on many projects. And, rightly so, it's better to make a good code base, rather than one that is littered with backdoors.

I wonder what could make this situation better for the maintainers of open source projects?

Public funding for security maintenance.

And serious taxation of tech companies.

Designing for safety helps a lot. Memory safe languages, reproducible builds, encoding safety properties in the type systems, and so on.

Sure, an attacker can subvert the types as well as the code, or use unsafe code, or try to tamper with infrastructure, but the more obvious it is that something is unsafe, the harder an attacker's job is.

The xz attacker introduced high-risk features over time and used them to justify weakening security controls and things that might have detected the problem. A culture of safety over the absolute best possible performance might help to make such attempts harder.

The problem with open source is that it's free software, so no one wants to pay for it. Therefore the developers don't spend enough time maintaining and securing it, and not enough time preventing social engineering takeovers.

I think we need to philosophize. Is some software “infrastructure” and some even “critical infrastructure”? Or maybe they should be new classes of public goods? There are huge risks that society needs to address and I don’t think the non-profit (open source) market is providing it. And maybe not even the for-profit market.

I don’t think open-source project leaders have the resources to fight this risk on their own. We should discuss if there is a role for government, just the way government pays for security (police) and protects critical infrastructure.

Would it be interesting if Github (and others) had a program where they would verify people using the same regulations the banking industry uses for KYC (know your customer)?

Optional step for developers to show they are who they say they are?

No. This is a terrible idea

Lol bluechecks for programmers. I think a better idea is people actually read the code before merging it. The more people use your project, the more suspicious you should be.

People will just buy and sell verified accounts like what happens on every platform.

No. Let's stop having these ideas of a totalitarian world. Instead, find solutions for zero-trust environments.

How is that totalitarian? Bureaucratic - yes, totalitarian- hardly.

Hostile takeover of FOSS projects leading to nefarious outcome for users is indeed nothing new. Oracle for example has been playing that game for a while (OpenSolaris, Java, MySQL, OpenOffice,...).

Also beware of weaponized CoCs and the paradox of tolerance.

https://news.ycombinator.com/item?id=30726098

https://en.wikipedia.org/wiki/Paradox_of_tolerance

https://nationalpost.com/opinion/the-tyranny-of-the-bureaucr...

Technical people undersestimate the power of social engineer because, most generally, we look for extreme problem solving in security incidents and social matters is not the expertise of the field. Wenshould be aware that mane grandiose hackers as Kevin Mitnick knew well this art. I highlight this because it is a weakness that is not solved by any of the artifacts you learn at university.

I think scamming, in general, should be taught early on in schools, as well as finances.

Seems like this would mostly raise suspicion for little gain, wasn't there a more robust solution of signed distributed reviews so you could simply pin the dependency at a state where reviewers you've explicitly added as trusted review code (and similarly after you review you can express that for the others to rely on)

Of course, this won't magically increase the time spent on code review, but will at least allow currently internal reviews to be available

> Pay attention to how interactions make you feel. Interactions that create self-doubt, feelings of inadequacy, of not doing enough for the project, etc. might be part of a social engineering attack.

Thus all ungrateful tickets whining about the project maintainers' lack of activity or brow beating then into action must be seen as a threat. How interesting.

The guidelines are laugthably naive in the light of current global security environment and level of threats involved. Who said a long standing member of community can't be a threat? Who checks identity of contributors? All I know it's enough to have an email to create a github account. Is FBI checking their credentials?

it appears that this organization is repeatesly agitating for "threats" publicity in open source.. what is the motivation?

https://news.ycombinator.com/from?site=openssf.org

They're an open source security foundation. Their entire purpose is to fight those threats. One way to help flight them is to bring awareness to them.

It doesn't even have to be a server like ssh. It could be a client side project engineered to somehow deliver all your ssh keys or bitcoin wallets. There is no reason backdoors couldn't stealthily phone home from client side applications.

The crazy thing about the xz issue was, that xz is not even a dependency of openssh, but of systemd. And the xz backdoor exploited the systemd integration of openssh. This exploit was invisible to people that tested plain openssh without one of the most common integrations into Linux.

When an existing maintainer decides to onboard a new maintainer, announcing to the community can also be a good step in securing the project. It could result in additional scrutiny from community members.

There's an awkward reckoning in open source software about inclusivity and protecting the long-term security of projects coming.

Authors from several countries were already suspicious, such as Iran. Anyone from Russia and China or unknown places are all potential risks now.

Combined with recent inclusive ideologies, it’s gonna cause hard conversations. There will be a furthering in segmenting the Internet. Why fight contributing to an open source project when you could fork it and contribute with your allies?

For true enemies, there’s no risk to licensing or copyright issues. You can merge changes from the original, no problem. China even falls into this as there’s a limited ability for US companies to litigate within the country.

People think the Network State is hot, but at the end of the day, the Internet still has borders.

Would those countries not have similar concerns about US maintainers? The larger issue is successful projects with too few active maintainers.

this is a wild prediction to make and disturbingly regressive

FOSS is one of the most beautiful examples of supranational collaboration, and is in my experience much more integrated than the web at large, in a way that has nothing to do with "recent inclusive ideologies"

I don't see how blocking contributions from people in Russia etc will help. Malicious actors can simply falsely claim to be American. Is GitHub going to start verifying citizenship? Even if GitHub did that, it likely wouldn't be too hard to fake.

> Is GitHub going to start verifying citizenship?

As an American company they must presumably already do this to avoid violating sanctions, and least for anyone giving them money. It’s not a huge stretch to imagine they could also do so for free tier users.

I don't think they need to verify citizenship. I think IP geolocation is sufficient to comply with sanctions. That's not going to stop a malicious actor though.

And to be honest, it's not like getting US citizenship for their agent is difficult for a government agency. The same goes for most other countries.

Keep in mind that most places allow you to literally buy citizenship through investment. The amount you need for a country like US is prohibitive for the vast majority, but, again, is not really a problem for another government.

i dont think maintainer changes is even the endgame for this stuff. its hard to get a new person in, but a nation state can likely more trivially attack a current maintainer.. everyone has a button somewhere. the only solution to this is tooling which can flawlessly reason about code changes being malicious or not, being applied to every change in a project. and then still its a lost cause. a lot of issues and vilnerabilities come from how softwarw interoperates witj other software. will you be able to reason about all possible package combinations and how they are secure or not when they come together in certain ways?

it should be easier to write systems from scratch, rather than to have to use third party code for everything. computers currently are not condusive to this. they need to be built different, to allow software to be built different.

maybe while we are at it we can also make it so computers reduce complexity in peoples lives instead of adding to it.

> it should be easier to write systems from scratch, rather than to have to use third party code for everything. computers currently are not condusive to this. they need to be built different, to allow software to be built different.

Yes.

We also need to encourage user scripting of first party library APIs on devices.

iOS Shortcuts are a step in the right direction, but they need better tooling to maintain and distribute source-controlled shortcuts.

theres definitely improvements ofcourse. apple is not wrong trying to have more of the chain as a single vendor. i would hope amd/intel and such places might offer more help also to implement their devices easily. (implementing amd64 is really difficult imho, only acpi has some good code from the vendor and thats such a small part of whats needed).

we know kot to build a house on a bad foundation, but somehow built our techstack on a flimsy one (no one to blame, just times changing..). reinventing the wheel is the way to go, but ofcourse commercially and maybe generally kind of inviable as likely it would breal everything. i hope as stuff moves forward perhaps theres some tech leap that would allow this to naturally happen. some other architecture or so which is better and requires the rethink/rewrite.

i spend my days trying to reason about different foundations (software/firmware), but its an impossible mission, and for me merely a thought excersize. cant expect anything practical to come out of it unfortunately. and i think this last part is part of the issue. 'open source' has not the resources to fix the issues we are facing. its not meant to.

> we know not to build a house on a bad foundation, but somehow built our techstack on a flimsy one

Good analogy. Extending it further, homebuilders have liability and regulation for safety, while software has been a contest of incentives for creation, extraction and influence. With the convergence of "cyber" and physical reality, liability is coming to software development.

Alan Kay's VPRI has a few papers on new approaches to software, https://tinlizzie.org/IA/index.php/Papers_from_Viewpoints_Re...

https://tinlizzie.org/VPRIPapers/M2013004_agere.pdf

  The software for today’s personal computing environments has become so complex that no single person can understand an entire system. Our group’s early experiences with personal computing led us to understand that the essential model of personal computing can be expressed much more compactly. Our group engaged in.. the STEPS project) to materialize that vision over the last six years.. There are various meta-language implementations. A new stream-processing language called Nile was invented. The syntax of Nile allows a fully-featured vector graphics engine.. to be written in a clean, mathematical manner in less than 500 lines of code. 

 .. Another direction is to take the idea of loose-coupling to the next level; objects should not know about other objects directly but should always negotiate and “find” other objects.. J.C.R. Licklider already foresaw the need for program components to discover each other on a huge network of computers. From that viewpoint, what we are trying to do is to carry the vision forward.

Thanks a lot for the elaboration and resources, very interesting!

This article is trying hard to sound like it is based on years of learnings, but honestly every point in here just reads like it was cobbled together after the xz incident.

I'm not so certain that the `safe_fprintf` to `fprintf` swap was ever itself meant to be malicious. There's some speculation about the addition of strerror but again.

What about hostile takeover of existing maintainer accounts?

Is there a list of these projects that are 1 to 5ish people maintained, like the mentioned XZ Util. Would be nice to have some sort of monitoring changes in these.

Somehow we got to the point when we need something like FreeBSD key signing parties but we surely can't have these for everything actually.

"Good" that Microsoft now owns GitHub. They could now provide their AI tech to find out (and sell) which social engineering methods have worked out successfully on open source GitHub projects. I.e. which socially engineered PRs had been accepted and which not. And then train their models to improve PR acceptance right. Allowing to automate or at least enhance the entire project communication for best acceptance rate. #NSAKEY

This article, perhaps true, but it somehow seems to me also a way to gain certain OpenJS publicity.

I initially expected this to be about how Vercel/Next is trying to takeover React and morph it into Vercel.js

If the "Jigar Kumar" kind ends up in a CIA black site mailing lists will be a lot more enjoyable.

People, hear me please! I'm good software engineer, where I could find job?

Thank you!

PS I'm in Kyiv, Ukraine, here is war and at the moment I cannot leave country, but I'm very motivated to work from home, and I have good fast reliable internet connection and power is also reliable here.

The perils inherent of FOSS and letting random people in.

Like Microsoft did with GitHub?

the September that never ended

KYC: know your contributor

I now have access to his phone without traces great job!! (geniusspyhack at gmail com)

> XZ Utils cyberattack likely not an isolated incident

and yet they haven't provided any other examples.

The fact this one got caught looks borderline miraculous though

So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library, so they control it from inception?

Great that we'll finally get state-sponsored open-source development :D

US gov has encouraged finance/tech industry to invest in the security of OSS supply chains.

OpenSSF members: https://openssf.org/about/members

2021, $10MM, https://openssf.org/press-release/2021/10/13/open-source-sec...

> Financial commitments from Premier members include Amazon, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members Aiven, Anchore, Apiiro, AuriStor, Codethink, Cybertrust Japan, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift, and Wind River.

2022, $5MM for 10,000 OSS projects, https://openssf.org/press-release/2022/02/01/openssf-announc...

> Following a meeting with government and industry leaders at the White House, OpenSSF is excited to announce the Alpha-Omega Project to improve the security posture of open source software (OSS) through direct engagement of software security experts and automated security testing. Microsoft and Google are supporting the Alpha-Omega Project with an initial investment of $5 million.. “Omega” will identify at least 10,000 widely deployed OSS projects where it can apply automated security analysis, scoring, and remediation guidance to their open source maintainer communities.

2022+2023, $4.8MM disbursed to ten (not 10K?) OSS projects, https://openssf.org/blog/2024/02/16/alpha-omega-2023-annual-... & https://openssf.org/blog/2022/12/14/alpha-omega-project-firs...

  Eclipse         $1,150,000
  NodeJS          $579,000
  Rust            $920,000
  Homebrew        $175,000
  jQuery          $350,000
  OpenSSL         $127,968
  OpenRefactory   $50,000
  Prossimo (ISRG) $530,000
  Python          $400,000
  Linux Kernel    $620,000

Neat that jQuery gets so much. I guess they have a ton of stuff on jQuery still (and probably will forever).

Why did Eclipse org get so much and Apache org none/less? In my experience, the footprint of Apache exceeds anything else in enterprise programming.

This also struck me as a bit odd.. even more so when you consider that over recent years, eclipse's general usage over time has decreased

Are OpenSFF members using Eclipse sub-projects in the financial services industry? In automotive/embedded, Eclipse hosts the safety-certified OSS ThreadX RTOS (formerly Azure RTOS), which runs on 10B+ devices, https://finance.yahoo.com/news/eclipse-foundation-showcases-...

Ahhh, I was thinking they were just funding the IDE.

It would be helpful for projects funded by OpenSSF Omega to publish details on how they prioritized use of the funds to improve supply chain security within each project.

Tons of modern and really critical development happens on Eclipse-based environments. Two examples I can think of off the top of my head are

- DBeaver (very widely used to connect to production databases)

- STM32Cube IDE (for embedded development in all sorts of devices)

TI's Code Composer Studio is also eclipse based.

Eclipse manages a distribution of Java and the Jakarta libraries, formerly known as JavaEE/J2EE. Arguably Jakarta is a larger footprint, since pretty much every enterprise-like library or application derives functionality from it.

NSA's got to keep developing Ghidra

I expect the pay awards are based on the various OSS foundation thingies lobbying.

But protecting dev environments makes sense. Think how many supply chains an attacker can compromise if they can get at random dumb developer machines...

The ideal state is having the world's superpowers all devoting effort to improving open source libraries, but all catching each others' backdoors and at the end of the day improving security for everyone.

Web of trust, but all commits must be signed by at least 3 intelligence agencies from rival countries.

“Web of distrust”

Mutually Assured Commitment

Alternatively: mutually assured development.

  At least 2 rival legal Jurisdictions/Alliances/Spheres
  At least 2 rival state intelligence Agencies per Sphere
  At least 2 rival corporations per Sphere
  TOTAL: 2*(2+2) = 8

Widely used OSS projects are contested spheres of collaboration.

So the long game is rival countries are secretly collaborating, so we secretly have world peace!

Imagine all war stops and noone knows it

Nah uh! We are still warring! Israel winks at Gaza, Iran squeezes the U.S.A's ass.

Global violent deaths have been trending downward consistently since ww2, even given our new “permanent war” status. We simply just don’t have large-scale wars anymore.

Russia, China, Iran and NK cock-block development for years, because the MR “doesn’t represent their interests”.

Sounds a lot like how web standards work!

Apple’s behaviour specifically

This is independent of browser vendor

You mean like the US blocks all efforts to ban putting weapons in space?

Yeah, it is definitely an off the cuff incomplete idea. I think you’d want to structure things pretty carefully. Maybe somehow classify countries into: Hostile, Competitor, Unaligned, Friendly, and Too Friendly.

Maybe just ignore Hostile, try to find enough competitors to ensure at least one will review, require a couple unaligneds and friendlies, and then consider “too friendly” to be the same as your own country.

Like from a US point of view, if the US and the UK agree on something… I mean, that only counts as one point, right? We are too close. But if like half of the EU and India agree, there’s enough competing self-interest to let it through (keeping in mind that it is all open source, nobody wants to be caught doing something sketchy). And if China, the US, and any other non-5-eyes country agree on something, it must be fine. (I picked these countries because I think they are pretty uncontroversial, I’m definitely not going to try and list who’d be in the hostile group, that’s just asking for unproductive political squabbling).

Multiple possible paths, no veto.

But I have no idea how to fix the problem of: some countries look more or less trustworthy from others’ point of view; I think we can easily suggest a plan from the US point of view, but I have no idea how to get everyone to agree on what the actual state of a single source code repository is, since commits have dependencies. Maybe it needs to be more like a package manager.

This has been quietly happening for a good while...

I wouldn't say so.

* Bruce Schneier writing about the NSA: https://www.theguardian.com/commentisfree/2013/sep/05/govern...

* https://en.wikipedia.org/wiki/Bullrun_(decryption_program)

Sounds like asking for World Peace.

Mutually Assured Backdoors

> So next the attackers playing the long game will just set out to develop the next great everybody-uses-it open-source library

This already happened.

*cough* React *cough*

Ask yourself, why would rogue AI and famous human impersonator Mark (short for Mark Zero Ai) Zuckerberg make an open-source UI library for everyone to use? /tinfoil

That said, who knows, maybe it already happened.

If it's an everybody uses it solution it will eventually be reimplemented as a part of the environment, like the browser or the kernel. The lifetime is limited and linking to a library like that wouldn't mesh very well there.

You can easily get two decades out of solutions like libjpeg, the GNU project, systemd, busybox, rsync, etc.

Relevant: https://www.youtube.com/watch?v=jgYYOUC10aM

A kind of similar thing happened with game key scammers. People will email the devs of hundreds of Steam games pretending to be a popular YouTuber, asking for keys for themselves and usually a few extra "for a giveaway". If they get the keys, they'll try to resell them for a profit.

At first you'd get emails from like, pewdiepie@outlook.com instead of pewdiepie@gmail.com. But you could usually check the YouTube about page to find the real business email and compare it.

So eventually the scammers started creating their own YouTube channels. They'd steal videos from other channels and reupload them, then get bots to add views and subscribers. Now the email matches the one on their channel.

One remaining tell tended to be the lack of comments, but it's been a few years since I had a game that was getting those kind of emails, and I wouldn't be surprised if they have good fake video comments these days too.

Here are a couple of examples of fake channels I have saved from a few years ago:

https://www.youtube.com/channel/UCzOhUFVqJSGk20eB0kFCyOg

https://www.youtube.com/channel/UC_TgLJm0paPjmJQTWaHqDhQ

Relevant xkcd: https://xkcd.com/810/

How do you know those two channels are "fake" or "scammers"?

I think I have a good eye for these things and worryingly they just look like the normal low effort youtube chaff but I wouldn't have thought fake/scamming.

Some common indicators (though this may have changed - I can only speak for ~7 years ago):

- Weird view counts. Strangely consistent, random sudden dropoff to near zero views, etc.

- No voice commentary. Can't steal videos from different channels if your "voice" changes I guess.

- A whole set of videos uploaded at once. This was more obvious when the linked channels were still active since you'd see like two rows of "2 days ago", then a bunch "1 week ago", then a bunch "3 weeks ago" etc.

- Social media etc links either missing or super basic.

- Few and generic comments vs. amount of views.

- Channel description generic, sometimes copied from other channels.

- The two I linked haven't done it, but some I saw were uploading long-plays of games split into many parts, I guess to easily pad out their total number of videos.

Another thing they were doing at the time, was changing their channel name and banner after a few weeks or months and then emailing again pretending to be a whole new channel. Easy to spot if you still had the old link and it was the same.

The second one I linked also mysteriously turns Russian if you scroll back far enough. Bit unusual for someone with their location listed as USA.

The solution is blockchain! /s

> Great that we'll finally get state-sponsored open-source development :D

Suspicions are very old: "Report of FBI back door roils OpenBSD community" (2010)- https://www.cnet.com/news/privacy/report-of-fbi-back-door-ro...

Also TOR being overtly created and sponsored by the US government, leading to some distrust

Or even better: push a cryptographic protocol with a builtin weakness as a standard and deprecate others as "insecure."

Any implementation would be vulnerable.

We need KYC for open source--call it know-your-maintainer. It's only a matter of time before there's a really serious hack and this becomes imperative.

Reply on news.ycombinator.com