What I’m understanding from the post is LLMs made finding security vulnerabilities trivially easy (anyone with 5$ credit can throw the repo at one), so the sole maintainer came out of semi-retirement to address them and also future-proof these new advances a little by building a new and improved test suite, and in the process the new version broke some edge, but valid, usecases for some users.

Then a lot of people started flaming the github issues (I read the thread lol) without having any actual bug to report, and blamed “slop vibecoding” for it because they saw Claude was a contributor but didn’t check any deeper. Claude was used to build the test suite once the parameters for it had been laid out, that’s it.

One thing everyone has to agree with is LLMs have definitely changed how software is built. I’ve seen vulnerabilities surfaced with LLMs; it’s really easy. You just clone the repo, open your agentic interface, type “find security vulnerabilities in this repo, test them to prove they actually exist and then make a report grading them by level of importance” and it will do it.

That’s not the scary part. The scary part is now anyone can find them and then exploit them. the LLM will happily make you code for it. This is where the software overton window is right now.

I’m not aware of what vulnerabilities exactly this patch fixed, but I know another project very well: wordpress. If you have a wordpress website, it’s going to get hit by dozens of bots trying default credentials (“admin” username and some simple passwords) every minute of the day. They do this automatically. They crawl the web to find wordpress websites by patterns, then try the credentials and move on if it doesn’t hit.

With LLMs, they can now find critical vulnerabilities in a couple hours and then update the crawler to use them.

That’s why I say LLMs are changing how software is going to be built moving forward. It already is changing how we engage with software, both ethically and unethically.

It sucks if it breaks your workflow and you have to stop doing backups until your problem gets fixed in 3 days or 2 weeks, no question about that, but you also kinda have to patch security bugs when you find them. The thing is, these vulnerabilities have always been in the code, for potentially 20+ years. they just went unnoticed.

And it’s happening time and time again on Linux these days, I assume because so much of it is open, and because it’s becoming more popular as a platform. So what will happen moving forward? There’s already been the Shai Hulud worm (banger name tbh lol) and Copy Fail in the past 2 months. CopyFail needs only 10 lines of python and was apparently partly discovered with LLMs. Clearly Linux being free of viruses because “it’s not popular enough to make one for it” is not going to hold much longer. Though at the same time, I don’t have a frame of reference to know if it’s just par for the course to find so many vulnerabilities on Linux systems (having only been using it for 6 months).

I don’t participate in software maintenance so I’m not sure what the best practice usually is around these sorts of updates. I doubt it’s the first time rsync (or any package) has caused what they call regressions. I don’t feel like I can really expect a solo maintainer to know every single usecase for a package that is used by millions of people. The sheer number is impossible, but like I said I don’t know if there’s already solutions that have been found for this. I also feel like if you rely on rsync that much then is there any reason you would update as soon as a new version comes out? Maybe part of the problem was that it was packaged as 3.4.2 -> 3.4.3, making it look like a minor upgrade that you would expect would only fix bugs. Don’t have enough info to say but the flaming from people who just wanted to complain about AI was not helping. I read the thread, there were like 2 actual issues (if undetailed) and everyone else was just complaining. Meaning they didn’t run into problems themselves, if they even updated. they just wanted to complain.

So I guess this is the best practice I was wondering about. Someone opens an issue on the repo, dev fixes it and then adds a test to the suite to make sure it doesn’t break again in the future before shipping an update. I don’t really know what else they expect him to do differently, especially since these usecases were, by definition of breaking now, not actually handled in the test suite earlier.