Over 100k Infected Repos Found on GitHub

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?

That sort of thing happens because there's so much spam and malicious activity, such as the thing reported in this story.

Indeed. My parents (age 80+, father was an engineer and gadget freak) flatly refuse to use smartphones. My dad has a bit of trouble with the new big-screen TV but can figure things out. My mom just can't cope with the new remote and user interface. My dad's enough on the ball that he doesn't fall for scams, but I despair for people who aren't prepared for this (or who don't realize that email is untrustworthy).

All this digital stuff falls naturally to me, but for the most part, people my age and older really don't cope well with the digital world. I'm an exception because I got my feet wet in the mini/timesharing environment, just as personal computing was beginning to take off, and didn't lose interest.

Also, how well are we really teaching the next generation? I see both good and bad in that regard, with Pi, Arduino, etc. being the brightest spot, and locked-down ecosystems and pervasive surveillance the darkest.

And, of course, there's the whole culture problem. The notion of "computer literacy" went from "knowing how to use a computer" to "knowing how to use Word and Excel" almost overnight. Are schools actually using things like the Pi and Arduino, or are we leaving it to parents to get such things into their hands?

"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 the same extent in .NET is that .NET was relatively late to the automated package management scene. NuGet is relatively young, and, as of the last time I got paid to do .NET work, very few of the projects I worked on had actually adopted it yet. So, at least back then, .NET had a stronger culture of well-focused projects that didn't take on enormous transitive dependency trees.

I would also compare this to the recent news about Boeing. Theories abound about why it's gone down the tubes. The one that I find most compelling, though, is that, over the past couple decades, they have focused on moving more of their production out to third-party suppliers, and also cost optimizing their outside supply chain. And that has made their supply chain increasingly difficult to actually manage. The details are different, but in broad strokes it looks a lot like modern software engineering culture regarding supply chain - and some have even argued that this is where Boeing got the idea.

Meanwhile, the place I've worked where I found dependency management to be the least annoying - and where we had the fewest problems with quality - was a financial firm that had banned package managers for supply chain security reasons. There's something to be said for code that absolutely will not change unless you explicitly change it. I've heard similar sentiments expressed by friends and acquaintances who work at Google.

We did write a lot of stuff for ourselves where others would just import a package, and that was good, too. The in-house implementation would do just what we need, and be held to a higher coding standard. So it was easier to understand, easier to debug, and easier to modify as requirements change. And here's the thing: writing it in the first place is a one-time cost, and one-time costs have good amortization characteristics. The recurring costs of dealing with code that's trying to be everything to everybody can easily be greater in the long run. They generally don't amortize; they compound.

Rich Hickey really got me to see how this kind of phenomenon works in his talk "Simple made Easy." Long story short, simple is different from easy. The simpler option tends to look harder up front. But it also tends to be easier in the long run, after you give second-order effects some time to take their toll.

Given the code that I've seen LLMs write so far I'm not too worried for now. They are very useful to write a lot of boilerplate code quick so I use them, but they also tend to write the wrong code often and so when I use them the code is well reviewed.

Of course if this is underhanded code (not to be confused with obfuscated - I won't accept obfuscated code from LLMs) I might miss things.