|
|
Subscribe / Log in / New account

silly premise

silly premise

Posted Sep 2, 2025 15:13 UTC (Tue) by HenrikH (subscriber, #31152)
Parent article: The hidden vulnerabilities of open source (FastCode)

Now imagine the very same but a company programmer doing copy+paste from a similar LLM to the company closed source code... This is IMHO a very silly proposition that have zero to do with open source. Also the XZ attack was by giving the attacker maintainer rights to the repository, not that any of the submitted code passed/didn't pass any code verification.


to post comments

silly premise

Posted Sep 2, 2025 15:54 UTC (Tue) by wtarreau (subscriber, #51152) [Link]

I agree with you. This is just clickbait trying to surf on the AI-everywhere wave. Whoever has already got an AI-generated report will tell you that they're quickly recognized and that the bot is totally unable to engage in any form of sensible conversation. In practice, AI reports are refined multiple times before being sent, and it's even likely that the chat session they emerged from no longer exists, thus it likely requires the reporter to try to restart a session from scratch with a bit of context and our question and see the bot generate tons of hallucination crap that they just cannot post.

Right now you almost never get a response to any context question for these reports.

And when chat bots will be smart enough to discuss the review in real time and make it look legit, they'll also be smart enough to run the review as well. Bots will talk to bots and this will go who-knows-where.

On the opposite, I wouldn't bet much on the long life of closed source where code is already being generated in part by chat bots but there's nobody to control it. The only ones that see it are those doing it for a living and who are incentived on disassembling code, running bindiffs etc where the problems remain visible.

silly premise

Posted Sep 2, 2025 16:02 UTC (Tue) by jafd (subscriber, #129642) [Link] (1 responses)

> Also the XZ attack was by giving the attacker maintainer rights to the repository, not that any of the submitted code passed/didn't pass any code verification.

Note that in the specific XZ case, the bit where it all went downhill, was not in the repository access itself, but in the ability to roll out releases and having things in the tarball that have never even been in the git repository — those who built from git didn't contract the vulnerability. One way it could be interpreted is that the commit history makes nefarious things way shallower than delving into release tarballs which usually also contain generated code.

silly premise

Posted Sep 10, 2025 16:33 UTC (Wed) by zwol (guest, #126152) [Link]

It's true that a key piece of the XZ attack payload was only in distribution tarballs, but most of it was checked in, concealed as test data. Given the same social conditions -- an overworked lone maintainer delighted to have help from anyone -- I can easily imagine the same kind of attack being just as successful (or more!) with all of it checked in.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds