[jochem9]

This is the third HN post I read on this topic. Everytime the same tweet (or whatever it's called for mastodon/bluesky/etc). Did anyone actually debug the issue?

Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?

[cwillu]

https://github.com/RsyncProject/rsync/issues/929#issuecommen... has a partial list

[Lerc]

That is a list of problems, not causes, which is what was being asked for.

It's possible it's some LLM randomness that caused bugs. That would suggest that some AI hygiene is in order.

If it is because of behaviour changes necessary to fix security issues, then the regressions might be from things that relied on unsafe features.

Do we know of actual specific causes yet?

[adrian17]

Yesterday's comment listed suspected commits alongside the issues: https://news.ycombinator.com/item?id=48334270

[JdeBP]

It's called a post, the same as you used for Hacker News.

And yes, I debugged one of the issues. I made the second comment in one of them. Markus Mayer did some debugging, too.

Then I had to deal with something completely unrelated to computers for the rest of that day and several days thereafter, and came back to this.

The problem with compiling code that used new kernel features was a bit poorly done. Anyone with any experience knows that a simple #if defined(__linux__) , which is a platform test, does not cut it for feature testing. M. Mayer went with an autotools test, which is what I'd have done too.

The problem with the on-the-wire protocol is a tricky one, and caused by suddenly being conservative in what rsync accepts apparently without much testing of what out-of-range stuff in-the-wild rsync sends.