In 2020, my friend anarcat published the CLA Denial-Of-Service attack, an interesting musing on the possibility of weaponising CLA, boiling down to:
- find a critical bug
- figure out a [non-trivial] patch for the bug
- publish the patch in their issue tracker
- forever refuse to sign the CLA
The obvious solution to this conundrum is to perform clean-room reimplementation: have a person read the patch and produce a specification, then have a second distinct person read the specification and produce a patch. It's not a silver bullet, as the less trivial the change, the lengthier the specification, and thus the lengthier and complexer the implementation. And because of course, complexity doesn't scale linearly, large changes are horribly annoying to reimplement.
On the bright side, there is a symmetry in the efforts: an attacker has to spend time to create a non-trivial change that warrants the effort of being clean-room'ed. The ubiquitousness of LLM didn't change this balance, it only lowered the costs for both sides: telling the AI God du jour to write code is cheap, and so are clean room reimplementations. While pure-AI outputs can't be copyrighted, having an actual person shepherding it and sprinkling some authentic human changes and touches it cheap and should be enough to stamp a copyright on top of it.
But not everyone is comfortable with code produced by AI/LLM, with some projects banning code that isn't 100% human-created. This introduces an imbalance, as having someone volunteer to read the changes and produce a spec that could then be used by a different person to implement the fix is orders of magnitude more costly for the project than for an attacker to generate slop, likely wing to Brandolini's law
Slop can, of course, be ignored, and small desirable improvements are trivial
to reimplement, so besides identifying slop, it's not a big issue anyway. An
easy way to spice things up would be to find a security issue with a
non-trivial but-still-straightforward fix, send a pull-request with
Co-authored-by: Claudepilchat, and argue that the clean-room reimplementation
is erringly similar to LLM one, which would be a license violation, gasp!
Another more impactful possibility would be to use a time bomb, by sending a proper legit-looking invasive change. It could be reviewed, merged and shipped, only for the author to reveal, 3 months later, that the change was actually done by an LLM, oops-sorry-I-forgot. Would the project spend time in doing a tedious reversing of all the changes? If so, what if the change was addressing a complex security issues? If the change isn't reversed, does it mean that the "no LLM" policy is selectively applied?
Now, I'm not a fan of the "incinerating the planet and feeding unfathomably high amounts of human-needed resources to train glorified text-prediction engines so that we can all drown in slop and witness every artistic endeavour be sucked dry and regurgitated in the form of soulless copy-pasta every-fucking-where" plan, and I think it would be real nice to stop implementing it right now. But, on the other hand, I don't think that a self-righteousness attitude is the appropriate position to adopt: people are going to send slop to your project, people are going to cheat, it will happen. Having a pragmatic position on this mess, like "we ask you not to use LLM in any way, shape or form, don't be a dick" paired with a trusty trigger-happy ban-hammer conveys the same message while avoiding painting your project into a corner.