Re: Ballot option: Allow AI-Assisted Contributions

"Theodore Tso" <[email protected]> Sun, 2 Aug 2026 14:46:17 -0400
Newsgroups gmane.linux.debian.devel.vote
Message-ID <[email protected]>
On Sun, Aug 02, 2026 at 08:14:25AM -0500, Bas Wijnen wrote:
> What started it was that the rsync maintainer decided to use an LLM and they
> *broke* rsync. Only when people noticed their backup systems were no longer
> working, did those people start reading the changelog. There they found out
> the reason that it was broken, namely that the maintainer had apparently
> decided to start using an LLM (and they obviously weren't doing a careful
> review and/or using good tests).

The relationship between those two events are a bit more complicated
that that.  The rsync maintainer (Tridge) had turned things over to a
successor many years ago, with a promise that if his successor needed
help, that he would render that help.  Many years later, after Tridge
had retired from his day job, the then-current maintainer had a number
of personal issues and could no longer fulfill the maintainer
responsibilities, and so Tridge agreed to step back into maintainer
role.  Several weeks later, rsync started getting flooded with a large
number of security bugs that were discovered using LLMs, and many of
which were extremely high severity bugs, since rsync can be a
publically available service that in some cases, does not require that
you have login credentials before downloading publically available
files.

Now, over the years, rsync had grown a large number of options, which
interacted in "interesting" ways, and Tridge realized that the current
test infrastructure wasn't up to snuff.  So in addition to *fixing*
the security bugs, Tridge started creating a new test infrastructure
using LLM's.  But then Tridge had to decide whether to release a
bugfix release which fixed the *known* security vulnerabilities, or to
wait until the new test infrastructure was fully completed.

Tridge chose to release the the security fixes.  Unfortunately, there
were a number of corner cases where both the old and the new test
infrastructure didn't catch the fact that the security fixes broke
those corner case configurations.  Of course, it was the people who
had those corner case configurations that complained --- loudly ---
and blamed the LLM-generated commits as the root cause of the
breakage.  But in fact, that wasn't the case.

> The story here is not "if you use an LLM, you risk being harrassed". The
> story is "if you use an LLM, you risk breaking your code". That is
> problematic in all cases, but especially for software which has been stable
> for decades.

Incorrect.  The use of LLMs wasn't the reason why the code was broken,
unless you want to blame the security vulnerabilities that was
discovered by *other* people running LLMs --- some of which might be
malicious attackers, nation-state agencies like the NSA, KGB, MSS,
GCHQ, etc.

If you really want to read about the full story, I encourage you to
read these two posts.

https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
https://medium.com/@tridge60/rsync-3-4-4-released-life-in-the-security-trenches-0f4ad157cf5f

For me, it's not that the people who are anti-LLM will issue death
threats.  It's that many of the anti-LLM people aren't bothering to
understand the real issues for maintainers who have to deal with the
world as it exists, not as the world the anti-LLM people wish it could
be.

Again, I ask the question --- what is more important?  Protecting our
users against security vulnerabilities?  Or holding a pure, "All LLM's
are evil, and most be avoided at all costs"?

Cheers,

    	      	      	      	 - Ted