Comment by himata4113
1 day ago
Looks fine? most of the commits are tests, ci, docs and issues that could cause memory corruption / hidden bugs rather than any new feature development. Of course it's unfortunate that it caused this bug to surface and it would be curious to investigate exactly why this happened, maybe the "safe" c operations have different (unexpected) behavior instead of immediately pointing out that "ai bad". I think patching issues that could cause future CVE's is pretty important especially because rsyncing a file -> client compromise could be pretty devestating as it often runs unsandboxed.
Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers. (edit: if someone hears "you are irresponsible if you don't let claude review your code", it would be pretty natural to let AI review your code and fix issues without knowing the full implications of it)
I suspect this commit: https://github.com/RsyncProject/rsync/commit/4fa7156ccdb2ad3..., appears to be changing behavior and changes like these shouldn't be in a patch version (unless it's an active security exploit).
Yeah this is how software development works now, no matter how much anyone wants to disagree with it. The technology is here, you can't put it back in the box. If your tool has AI agents trying to find exploits 24/7, you'll need something comparable.
It is worth figuring out the new science of software engineering to get it right.
I suspect we are going to find plenty of new techniques that make this sort of development work better. After all, it took fifty years to arrive at our best known (unit test + reviewable tiny change, get an LGTM) model of software development.
no, no, no. if we all stomp our feet and kvetch really loud, a Hawaii judge will declare AI illegal and order a global moratorium. all trillion dollar companies will immediately cease all AI activities, and then UN death squads will go door-to-door confiscating assault GPUs from the chuds.
Yeah but what are the downsides?
> Everyone is still learning how and how much AI should be used and we shouldn't be too harsh on opensource developers.
The main problem with using AI in open source software is that millions of people rely on your code, but you risk exposing them all to something unverified.
If millions of people are relying on free software, that's their problem, isn't it? The maintainer has zero obligations to them, and they are not entitled to anything. If they want commercial support or SLAs, they could tender an offer, or else they can fork it and maintain it themselves. I think the maintainer here is being a silly goose but it's their right to be as silly as they want in their own repo.
Well maybe we shouldn't then? Before LLMs some not just clueless but also malicious rando could've send a PR too. And the maintainers might've gotten burned out any and just said f-it and merged stuff randomly. I don't see how AI changed the calculation here much.
No reasonable maintainer would recklessly merge something he/she hasn’t reviewed. Well, those who blindly accept whatever AI outputs… perhaps it’s time for them to find another job.
Just because one offers software for free doesn’t mean there shouldn’t be standards.
7 replies →
Before, there was a chance to spot it (and things like XZ Utils backdoor were rare), now it will be well hidden in the ocean of slop PRs.
Yes, you risk reputation and still need to be careful. One way to try to mitigate is to write tests. Which is what rsync project is doing, too. But there's only so much you can catch alone.
And BTW, you're not distributing to millions of people as an author of the code.
There are distributions maintainers between you and the world, which can also intervene, and are responsible for what they distribute, build testing on many configurations/architectures/versions - and can decide to revert to protect users, etc. And often do.
FOSS authors themselves can't be expected to keep around outdated systems from 5 years ago just to test build compatibility, in 8 different architectures that someone may want to build their code with.
Very few projects have as comprehensive testsuite as say sqlite. You can never cover everyting, so the beauty of FOSS is that someone will come and tell you and send you a fix for their special system, and now everything is again fine for that one special person, or distro maintainer.
You also risk exposing users to any other error you make. That's called a bug.
Unless someone points to vibe coded/hallucinated code causing the breakage or provides clues that might indicate unreviewed slop code being committed and shipped, I'd hold my horses.