We should probably assume repositories like these are part of Copilot's and ChatGPT's training data until it can be proven otherwise.
so maybe they aren't hallucinating after all. (just using bad source info.)
Over 100k Infected Repos Found on GitHub
171–180 of 187 posts
Re: Over 100k Infected Repos Found on GitHub
#172Wonder if the whole curl + sudo shell script installer thing is going to come to an end any time soon? aka the whole "just run 'curl https://somesite/install.sh ' | sudo sh" to install our software Seems like it'd go very hand in hand with this infected stuff mentioned in the article.
Pro tip: use example.com for such examples, because it's reserved specifically for that: https://www.rfc-editor.org/rfc/rfc2606.html#section-3.
Re: Over 100k Infected Repos Found on GitHub
#173Wonder if the whole curl + sudo shell script installer thing is going to come to an end any time soon? aka the whole "just run 'curl https://somesite/install.sh ' | sudo sh" to install our software Seems like it'd go very hand in hand with this infected stuff mentioned in the article.
Pro tip: use example.com for such examples, because it's reserved specifically for that: https://www.rfc-editor.org/rfc/rfc2606.html#section-3 .
Good point, I just totally forgot. :)
Re: Over 100k Infected Repos Found on GitHub
#174This 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…
I'm not sure what of this is available in npm, but with crates io and cargo, there are crates like cargo audit and cargo deny that your pipeline can use to check for cve in your dependency tree. Your lock file maintains the sha256 of everything in the tree, so there is no need to mirror things to ensure they aren't modified if their repo gets hacked. Pinning a version a few months behind the newest seems to be the sw…
npm has “npm audit” which throws out so many warnings on nonsense like ReDos “vulnerabilities” in dev packages that everyone has learned to ignore it. It does active harm to the security of the ecosystem.
Re: Over 100k Infected Repos Found on GitHub
#175Earlier 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…
Totally agree - I think package managers that make it very easy to pull in huge transitive dependency trees are fundamentally making the wrong thing too easy. First all those dependences you pull in aren't necessarily dependencies because they are done at the package level. If I use one class/function from package A, I may not need any of the package A sub-dependencies - yet these package managers will pull them in r…
And that, in turn, enables a lot of really troublesome feature creep.
Last year one of the dependency hell hassles I had to deal with stemmed from MLFlow, a Python package for organizing and collecting results from machine learning experiments, had a hard dependency on LLVM. Why? Because Numba, a JIT compiler for accelerating calculations in Python, uses LLVM. Numba, in turn, is required by SHAP, a model explainability tool. Producing SHAP explanations, in turn, is baked into MLFlow as a kitchen sink feature that is not needed by typical users and could easily be supplied manually or have been included in a separate add-on library.
Probably the most upsetting version of this that I encounter is that Apache Spark has all sorts of known vulnerabilities in all the transitive dependencies it pulls in to support every imaginable feature. The Spark project has declined to fix a whole heap of them, on the grounds that Spark doesn't call into the code that has the vulnerability. For a while they even wontfixed @$#% Log4Shell. This is a huge ticking time bomb in my book. Because Java dependency management is such that your Java process typically only gets one version of each JAR, and, if you're using Maven for builds, which version you get is unpredictable. So Spark can cause applications that use both Spark and the affected library, and thought they were using a patched version, to instead get whatever old vulnerable version the Spark project has decided to stick with.
Yes, there are lots of clever things you can do to mitigate this problem. But they don't happen by default, and require extra effort and no small measure of specialized Java ecosystem expertise to get right.
Re: Over 100k Infected Repos Found on GitHub
#176As 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…
Doubtful like they said, while it's a 100,000 the fact is that thats still a drop in the swimming pool that is github, thats why it's lasting so long, because even though the number seems big when it comes to github its a relatively small number, which seems insane, and if a LLM is training it'll end up getting averaged out for the most part by the vast other swaths of code.
Re: Over 100k Infected Repos Found on GitHub
#177Earlier quoted context omitted.
Totally agree - I think package managers that make it very easy to pull in huge transitive dependency trees are fundamentally making the wrong thing too easy. First all those dependences you pull in aren't necessarily dependencies because they are done at the package level. If I use one class/function from package A, I may not need any of the package A sub-dependencies - yet these package managers will pull them in r…
And that, in turn, enables a lot of really troublesome feature creep. Last year one of the dependency hell hassles I had to deal with stemmed from MLFlow, a Python package for organizing and collecting results from machine learning experiments, had a hard dependency on LLVM . Why? Because Numba, a JIT compiler for accelerating calculations in Python, uses LLVM. Numba, in turn, is required by SHAP, a model explainabil…
Gotta say this is one thing i noticed when i started playing with Rust, sure there are creates for everything but there seems to be a pretty heavy effort to minimize deep dependency trees unless really needed, and when it's not the case people tend to avoid the packages like the plague i feel like.
Re: Over 100k Infected Repos Found on GitHub
#178Earlier quoted context omitted.
And that, in turn, enables a lot of really troublesome feature creep. Last year one of the dependency hell hassles I had to deal with stemmed from MLFlow, a Python package for organizing and collecting results from machine learning experiments, had a hard dependency on LLVM . Why? Because Numba, a JIT compiler for accelerating calculations in Python, uses LLVM. Numba, in turn, is required by SHAP, a model explainabil…
Gotta say this is one thing i noticed when i started playing with Rust, sure there are creates for everything but there seems to be a pretty heavy effort to minimize deep dependency trees unless really needed, and when it's not the case people tend to avoid the packages like the plague i feel like.
It's a rare day that I feel sad about doing something the way systems programmers like to do it.
Re: Over 100k Infected Repos Found on GitHub
#179Earlier quoted context omitted.
This seems like the “don’t use seat belts, drive safely” argument. Trust mechanisms in GitHub/etc can’t solve the whole problem, for sure. But some automated safety mechanisms at scale can reduce the risk for those who don’t follow perfect security practices, which has value to the world at large. Very few of us have the capacity to do even cursory validation for every update to every dependency of every bit of softw…
I’m not saying don’t scan code for vulnerabilities, I’m saying GitHub shouldn’t be the place that the scanning happens. A good place would be where the code is getting compiled /executed.
Are you saying github should not scan? I don’t think there’s a central planner who will enforce that scanning is only in one place.
Re: Over 100k Infected Repos Found on GitHub
#180Earlier quoted context omitted.
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.
Wouldn't it be easier (since they probably have very skilled programmers working for them) and way, way more effective to just set up a team and create a quality open source project with one or two extremely stealthy backdoors? Or just pay or threaten a struggling company or dev to insert them?
How would you secretly hide something like that in FOSS? And why would that be easier? It's seems to me that it's easier to inject into an existing company than to do all the work yourself. This is what they do with most things as I understand.