Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Social engineering takeovers of open source projects

openssf.org

Post reply on HN
Print view View original

81–90 of 379 posts

Re: Social engineering takeovers of open source projects

#81

Post by jrockway »

Der_Einzige wrote: post #76
arp242 wrote: post #71

Earlier quoted context omitted.

[flagged]

[flagged]

I don't think the "armed to the teeth" theory is correct. If you were right, people wouldn't honk at each other or otherwise involve themselves in any sort of road rage. But people rage at each other all the time, and only very rarely does someone get shot.

The reason people aren't walking around stabbing you in the eye with a needle is because there is no reason for them to do that. They gain nothing. They don't desire that it be done.

Re: Social engineering takeovers of open source projects

#82

Post by orthecreedence »

ilhuadjkv wrote: post #65

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?

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.

Re: Social engineering takeovers of open source projects

#83

Post by andix »

arp242 wrote: post #71
andix wrote: post #33

Earlier quoted context omitted.

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…

[flagged]

We know about the failed attempts, we have no idea about the successful ones, and the ones that are going to be successful in the future.

Re: Social engineering takeovers of open source projects

#84

Post by ClassAndBurn »

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.

Re: Social engineering takeovers of open source projects

#85

Post by mdavidn »

ClassAndBurn wrote: post #84

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…

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

Re: Social engineering takeovers of open source projects

#86

Post by andix »

galaxyLogic wrote: post #63
andix wrote: post #42

Earlier quoted context omitted.

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'…

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.

Re: Social engineering takeovers of open source projects

#87

Post by astrange »

devaiops9001 wrote: post #27

[flagged]

A free open source project is perfectly capable of attracting wreckers with no other motivation than that kind of person has a lot of free time.

(Example being the wave of "you need a code of conduct" discourse was started by someone who needed to look feminist because they were fired by GitHub for harassing women.)

Re: Social engineering takeovers of open source projects

#88

Post by nbk_2000 »

MichaelZuo wrote: post #72
victorbjorklund wrote: post #56

Earlier quoted context omitted.

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

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.

Re: Social engineering takeovers of open source projects

#89

Post by nyokodo »

victorbjorklund wrote: post #56
andix wrote: post #33

Earlier quoted context omitted.

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…

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

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

Re: Social engineering takeovers of open source projects

#90

Post by jongjong »

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.

Post reply on HN