[mattbee]

But there's been security fixes in most releases of rsync!

Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.

Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/

[izacus]

The part you're missing is that those "fixes" broke a lot of existing functionality.

[androolloyd]

Bugs are bugs and need fixing. How dense can people get.

[hdgvhicv]

Regressions are bad and need to not happen.

[krcz]

Regressions are bad and they should be avoided. Still, software engineering is a complex thing and regressions happened long time before coding agents were a thing. Unless one can pinpoint regression to changes that were more sloppy than the human-written rsync commits were I don't think coding agents are to blame.

[cbm-vic-20]

Seems like that it's not that coding agents are to blame, its that the people who are ultimately responsible for committing and merging the offending code are to blame, regardless of its origin.

[krcz]

Or no one is to blame, if the mechanism of the regression is complex and non-obvious based just on the patch itself.

[Lerc]

Would you hold off on fixing a security vulnerability if it caused a limited regression?

Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.

[izacus]

Which part of security fixing demands thoughtless generation of code slop without regression testing though?

I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.

[Lerc]

I am discussing outcomes, not methodology.

The methodology describes the effort you may be putting into something, The outcomes are about what results are you prepared to accept.

Would you ship an update with a security fix if it had been thoroughly tested was shown to have certain regressions but no worse security regressions? Would you refuse to fix the security issue until you could do so without any degradation?

It's clear that people can and do accept regressions for security updates. Spectre mitigations cause performance regressions. SharedArrayBuffer got taken away for a while. Being absolutist about things seldom helps.

I agree due care should be taken where possible, but I'm also prepared to accept that mistakes can happen even when people have worked diligently to find issues.

Since you have worked on major OSS projects. Have any of them shipped regressions unintentionally? Right now that is the only thing we have to go on, that these things happened. The degree of care taken is an unknown, as is the degree of LLM involvement. We might know more in a week or two.

If you want to condemn something based upon what might have happened you can specifically state what you think shouldn't happen, and that will stand regardless of whether or not it applies to the current incident.

Obviously "Thoughtless generation of code slop without regression testing" is unacceptable, but that is because the conclusion is written into the statement by saying "thoughtless" "slop" and "without regression testing"

If tridge says 'I gave it thought, I don't agree that it is slop, and I did regression testing' then you have nothing further to complain about, because the incident does not fall under the criteria you specified.

It's saying 'things that are bad, are bad'. The defence is to say 'well, this isn't bad'

[dash2]

Parent is agreeing with you.