[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <19e19c71ce3.89e18d29194892.4293867009907644019@roiai.ca>
Date: Mon, 11 May 2026 18:22:20 -0700
From: Tim Shephard <tim@...ai.ca>
To: "oss-security" <oss-security@...ts.openwall.com>,
"fungi" <fungi@...goth.org>
Subject: Re: Coordinated Disclosure in the LLM Age
Thanks for starting this discussion. I have reported a number of issues recently, including - #2149789, #2150261, #2149775, #2150316 - three of which are identified by the team as critical, and one as high. The oslo rabbit MITM is also critical, IMHO, but I agree it cannot be fixed without potentially breaking many poorly configured deployments and so must be 'Class B'. An awkward situation to be sure, but the solution is understandable.
For what it's worth my goal is not to 'mine security gold', rather I am trying to find and test potential solutions for sovereign cloud.
More to the point of the thread, I think there is also a more pressing issue adjacent to the disclosure-process question: large, long-lived projects such as OpenStack have a substantial backlog of legacy vulnerabilities and insecure patterns that are now becoming much easier to discover with LLM assistance.
That changes the risk calculation. Issues that previously required deep project knowledge, persistence, or specialized tooling may now be within reach of many more people. We should assume adversaries can use the same leverage, including for insider attacks and for chaining individually modest bugs across trust boundaries.
In that sense, this feels like a generational security event. The urgent question is not only whether embargoed details might leak through LLM use, but whether maintainers can harden exposed systems faster than attackers can rediscover and combine old weaknesses.
That argues for shorter exposure windows, more proactive hardening, and more attention to eliminating vulnerable patterns before they become practical attack paths.
Furthermore, it argues for assertive use of modern LLMs, especially for code review and vulnerability discovery. I have volunteered to help with this for the OpenStack VMT, and would be happy to do so again here.
Cheers,
Tim.
PS: LLMs helped with this email, and with more and more of the work I do. I think we need to move forward with these tools more deliberately and less fearfully.
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.
