[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <19e4e2af936.4b7051cf156989.7683180300004644154@roiai.ca>
Date: Thu, 21 May 2026 22:31:39 -0700
From: ROI AI <sales@...ai.ca>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Re: Coordinated Disclosure in the LLM Age
I understand the costs, but simply hanging all the dirty laundry out is counter productive. Working a change in public without going into sensitive details is reasonable, but pushing vuln reports to public is careless.
One of the most effective white hat approaches I've found to using LLMs is to farm reckless engineers who spell out these vulnerabilties in public and create roadmaps to exploiting and attacking software.
ROI AI
From: Jacob Bachmeyer <jcb62281@...il.com>
To: <oss-security@...ts.openwall.com>
Date: Thu, 21 May 2026 21:02:51 -0700
Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
On 5/21/26 01:51, ROI AI wrote:
> Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.
>
> By keeping the reports private, the OSS teams can deal with the issues more on their timeline.
>
> By making them public, they add timeline pressure and enable attackers.
>
> Why are you making it harder on yourself? It is the opposite of what you want to do.
You apparently do not understand. Most projects take keeping embargoed
security issues private rather seriously---and that *itself* has costs.
Further, the key issue here is the question of whether those costs have
any benefit when the issue was found using a tool to search for issues,
due to the risk of someone *else* using the same tool and finding the
same issue. If that other person is another whitehat, you get a
duplicate report. If that other person is a blackhat, you get an
in-the-wild exploit while you were carefully maintaining an embargo.
> [...]
>
>
> From: ROI AI < mailto:sales@...ai.ca >
> To: "oss-security"< mailto:oss-security@...ts.openwall.com >
> Date: Wed, 20 May 2026 22:26:21 -0700
> Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
>
>
>
> People are shooting the messengers here. The fact is - we are going through a generational security event due to the advancement of LLMs.
Maybe... we are definitely going through a generational event with the
amount of "AI" slop that has buried maintainers of major packages. Have
you forgotten already that curl had to cancel their bug bounty due to
excessive "AI" slop submissions?
> It is also both trivial and extremely effective to use Agentic analysis to filter security reports.
You advocate that maintainers blindly trust systems that are *known* to
be incapable of precise analysis. I understand talking your own book,
but there are serious externalities here and I cannot let this go
unanswered.
What if that "Agentic analysis" incorrectly filters out a report of a
genuine issue? Now the issue does not get fixed...
And just how effective is that analysis supposed to be at filtering out
"AI" hallucinations? Remember that the *same* hallucination-prone model
might be doing the analysis as made the bogus report. How, exactly, is
a model supposed to recognize its own hallucinations?
> As for 'duplicates', people are claiming this when I have seen little evidence. I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate.
The claim came directly from someone who *works* with those issues and
manages inserting them into a bug tracker. I am inclined to trust their
experience over your hand-waving dismissal.
You might also want to realize that "AI"-generated submissions are now,
in many projects, sent straight to the bit bucket, especially if found
to be invalid. You should not expect a response informing you that your
report is invalid, as most maintainers have likely stopped bothering to
send those.
> Moreover, if 'duplicates' are found, then that is a good signal for prioritization.
Maybe, if only in that duplicate reports indicate that a particular
issue may be "low-hanging fruit" and therefore already quasi-public. In
other words, duplicate reports could be a signal to dump the embargo and
move faster to fix the issue. (Remember that working under embargo has
costs? *Those* *costs* *can* *extend* *the* *time* *to* *patch.*)
> Let's stop talking about how the vulns are found and start fixing them with urgency.
Know what? This reads like "AI" slop... and now I look at the source
(< mailto:sales@...ai.ca >) and realize that I am probably debating a slop
machine tasked with promoting a product. I will send this anyway, for
the benefit of my fellow humans who will read this discussion and who
might---just might---recognize your marketing efforts as the slop they are.
> ROI AI
>
-- Jacob
>
>
> From: Alan Coopersmith < mailto: mailto:alan.coopersmith@...cle.com >
> To: < mailto: mailto:oss-security@...ts.openwall.com >
> Date: Wed, 20 May 2026 10:52:37 -0700
> Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
>
> On 4/28/26 07:58, Jeremy Stanley wrote:
>> I'm sorely tempted, both due to the increased volume and the risk of premature
>> disclosure, to just assume that any vulnerability reported as a result of
>> research using an LLM is trivially discoverable by others, and give up trying to
>> pretend there's any point to working it under embargo.
>
> Other maintainers under similar floods seem to agree:
>
> Linux kernel:
> - https://lkml.org/lkml/2026/5/17/896
> - https://docs.kernel.org/process/security-bugs.html
>
> DNS servers (BIND, Unbound, PowerDNS):
> - https://indico.dns-oarc.net/event/56/contributions/1233/
> - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf
>
Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
