Live data from Hacker News

Over 100k Infected Repos Found on GitHub

apiiro.com

131–140 of 187 posts

Re: Over 100k Infected Repos Found on GitHub

#131

I appreciate the developments. I hope blindly pulling code from Github will be seen as the risk factor that it is.

Not just GH. People add StackOverflow snippets, pretty blindly, and pull directly from personally-published repos.

I know what an unpopular opinion this is, with the HN crowd, but I think we need to completely reevaluate our dependence on dependencies.

I have run into people that Literally. Can't. Write. Code, without dependencies. Their skill is at passing LeetCode tests, and googling for dependencies. Their bosses like them, because they pass the interviews with flying colors, and get results really quickly.

I remember, a number of years ago, attending a meetup, promising to explain GraphQL, and, instead, it was a lecture on using a JavaScript GraphQL wrapper. I don't think that two minutes were devoted to the API, itself. I seemed to be the only person in the room, that was going "Whiskey Tango Foxtrot?"

For myself, I use a lot of dependencies, but I wrote almost all of them, myself. I have spent years, building a library of SDKs and modules that I can integrate into my shipping projects.

I have only two external dependencies, in my current projects. These are not ones that would kill me, if I was forced to go alone, but they do save a lot of time (an Apple Keychain wrapper in Swift, and a streaming JSON parser in PHP, for the record).

Re: Over 100k Infected Repos Found on GitHub

#132

Stupid question here -- whats the most efficient way to evaluate for vulnerabilities (i.e. remove the low level risk like 95% of the cases)? Is it trust the package manager or is there another quick way?

I’d love to be surprised, but I think there isn’t any way to evaluate for vulnerabilities other than read all the code (fairly carefully). I don’t think the ecosystem is set up to make it easy.

Re: Over 100k Infected Repos Found on GitHub

#133

As well as this being our regular reminder to be careful what you pull from public repositories and other sources, and to verify your dependency trees, it raises another question: If malware is massively prolific in public repos, how much does this affect LLMs and other automation tools that are trained using the contents of such resources? What are the chances that we'll see copilot & friends occasionally emit malwa…

I'm less worried about backdoors accidentally appearing in LLM output and more worried about backdoors being placed into LLM output by 3 letter agencies. Maybe not today, but certainly in a few years time.

That seems pretty risky and easy to catch. The point of these LLMs is to produce code, we know they aren’t very reliable about it, so you have to check the code. So, it is more likely to get inspected than a random GitHub project, right?

It also seems dangerous in the sense that… if there’s a type of prompt that is likely to create infected code, our intelligence agencies would, I guess, want it to hit our adversaries selectively. So they’ll have more rolls of the dice to detect it. So, it is actively creating a situation where our adversaries are more likely to have knowledge of the vulnerabilities.

Re: Over 100k Infected Repos Found on GitHub

#134

This sucks. Supply chain is such an issue. Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an npm release for it. But my project BrowserBox (lightweight virtualized web browser) only uses ~800 dependencies including all descendents, with only 19 top-level deps (cool your heels non-JavaScript folks, this is comparatively lightweight for a full stack boing…

"only uses ~800 dependencies" slightly horrifies me. I was horrified to see how much time I started spending fussing with dependency hell after I moved from .NET to Java about 10 years back. And I am currently horrified by how much time I have to spend doing vulnerability updates and fussing with dependency hell in both Java and Python projects nowadays. I think maybe the reason I didn't have this problem to nearly t…

I worked for some time at an industrial/embedded company, where in order to build all the software, you had to select "build all" in a menu, and it built everything - more than four million lines of code.

It was a build system which was a pure pleasure to work with, last not least I think because it did not try to solve problems which turn out intractable in the general case.

They are not going to have these supply-chain issues.

Re: Over 100k Infected Repos Found on GitHub

#135
post #123

Earlier quoted context omitted.

Unfortunately `npm i` has the same power. `go get` is the only common dependency downloader I am currently aware of where hostile code doesn't run at install or build time. I think we need better tooling for working in sandboxes, to at least compartmentalize the explosion. ChromeOS's "virtual machines can open Wayland windows on the main desktop" trick is neat, but the code needed to do that was less than clean or re…

What's the point? You're going to ship that code to your users, or run it against your production database. If you think it might be malicious, protecting the dev laptop shouldn't be the priority.

I run production services that don't even talk to a database, or that have minimal read-only access. And even for the ones with a lot of write access, having the database stolen/nuked (to be restored from backup) is quite different from handing over all of my browser cookies, or my gcloud/aws/k8s ambient authority credentials that are just sitting in a file (seriously, why is big cloud client security worse than SSH).

Re: Over 100k Infected Repos Found on GitHub

#137
post #122
post #112

Earlier quoted context omitted.

This is not a worthwhile trade. The person sending the PR should not send LLM code that they can't vouch for, under the expectation that reviewers will find any vulnerabilities. That's just dumping the work onto the reviewers.

It's a worthwhile trade. I've been able to produce a substantial amount of reliable, working code with the assistance of LLMs over the past year - code I would have not been able to produce otherwise simply due to lack of time. Why review code at all if you think your coworkers are infallible?

I think you are both saying that it is OK to use LLMs, but you have to check the output.

It looks like there’s been a communication hiccup or something; I think you are saying that the LLM user should treat LLM code as if it is written by an unreliable team-mate who might copy-paste from the internet, and check it.

Jprete seems to be talking about just receiving a PR from a person who didn’t do that checking and just directly is using the LLM code.

I agree with you, but I think it is worth noting that

> This is not a worthwhile trade

> It's a worthwhile trade

The difference here is not in whether or not the trade is worthwhile; you are just talking about two different trades .

Re: Over 100k Infected Repos Found on GitHub

#138

As well as this being our regular reminder to be careful what you pull from public repositories and other sources, and to verify your dependency trees, it raises another question: If malware is massively prolific in public repos, how much does this affect LLMs and other automation tools that are trained using the contents of such resources? What are the chances that we'll see copilot & friends occasionally emit malwa…

This sounds like alarmist journalist talk. What “malware”, even subtle backdoors, are sneaking into the LLM-generated code used in a piece of software that’s actually worth a damn?

There are certainly people slapping AI generated code into production in small projects without adequately checking them, leading to things like inadequate input validating leading to open XSS and injection vectors. With too little oversight in a more significant project it is only a matter of time before this happens somewhere that results in, for instance, a DoS that affects many people, or a personal data leek.

Given the way LLMs are trained, it might be unlike but it is conceivable that if they see deliberate back doors injected into enough of the training data, they'll consider it to be a valid part of a certain class of solution and output the same themselves. It is a big step again from deliberate back-doors to active malware, but not an inconceivable one IMO if large enough chunks of code are being trusted with minimal testing.

Re: Over 100k Infected Repos Found on GitHub

#139

Earlier quoted context omitted.

"only uses ~800 dependencies" slightly horrifies me. I was horrified to see how much time I started spending fussing with dependency hell after I moved from .NET to Java about 10 years back. And I am currently horrified by how much time I have to spend doing vulnerability updates and fussing with dependency hell in both Java and Python projects nowadays. I think maybe the reason I didn't have this problem to nearly t…

> I moved from .NET to Java Oh boy. That's just the first gate of hell. You should try JS!

I have. I used to be a GUI developer, back in the days when everyone wrote native desktop applications. But I noped out of it pretty hard after rich Web applications and Electron started taking over.

When I was in my teens and 20s, I enjoyed complexity, because understanding complicated things made me feel smart. That meant I had an incredible tolerance for needless complexity.

Now that I've been around the block a few times, though, I just don't have patience for that kind of thing anymore. It all reminds me of the Wallace and Gromit cartoons. Wallace is a very smart and clever inventor, and his inventions are very smart and very clever and very silly.

Re: Over 100k Infected Repos Found on GitHub

#140
post #122

Earlier quoted context omitted.

It's a worthwhile trade. I've been able to produce a substantial amount of reliable, working code with the assistance of LLMs over the past year - code I would have not been able to produce otherwise simply due to lack of time. Why review code at all if you think your coworkers are infallible?

I think you are both saying that it is OK to use LLMs, but you have to check the output. It looks like there’s been a communication hiccup or something; I think you are saying that the LLM user should treat LLM code as if it is written by an unreliable team-mate who might copy-paste from the internet, and check it. Jprete seems to be talking about just receiving a PR from a person who didn’t do that checking and just…

Yeah, I think you're right.

I don't think it's OK for a coworker to contribute a PR generated by an LLM without having already reviewed it and being ready to declare that they are confident in its quality.

Post reply on HN