On Mon, Aug 03, 2026 at 12:52:22PM +0200, Peter Krempa wrote: > On Mon, Aug 03, 2026 at 11:28:59 +0100, Daniel P. Berrangé via Devel wrote: > > From: Daniel P. Berrangé <[email protected]> > > > > Use of email for security disclosures is not a sustainable approach > > in the new world with countless LLM assisted security researchers. > > > > The old security approach has been to keep disclosures visible to > > a very small number of hand-picked maintainers, on the assumption > > that information has to be highly classified. This view is no > > longer valid with LLMs assisted research, as multiple people can > > report the same flaw within a short window of time. It is assumed > > that anyone with access to LLMs will be capable of re-discovering > > issues at any time. > > > > As such there is less compelling benefit to limiting the visibility > > of disclosures originating with LLMs. Rather than try to distinguish > > which disclosures come purely from humans vs those assisted by LLMs, > > just assume LLMs will be involved as that is the common case. Thus > > make disclosures visible to all maintainers immediately. > > > > By the same rational of repeated re-discovery there is also less > > benefit to applying embargoes to issues once a fix is available. > > Thus this proposal intends to make CVEs public as soon as a fix > > is proposed for merge. > > > > With this new open approach to disclosures, there is then no > > reason to have a separate process for disclosing regular bugs vs > > security issues. By using the regular bug tracker for security > > disclosures, the process can be simplified and gain access to > > better tools for tracking & triage than email offers. > > > > Thus the new security disclosure process is simply with bug > > tracking process with two add-ons: > > > > * The initial disclosure has the "confidential" flag set > > * The use of "CVE::Required" and "CVE::Assigned" labels > > to handle CVE allocation. > > > > This is essentially identical to the process adopted by QEMU > > last month which has been successful at scaling the triage > > process. > > > > Signed-off-by: Daniel P. Berrangé <[email protected]> > > --- > > docs/securityprocess.rst | 94 ++++++++++++++++++---------------------- > > 1 file changed, 43 insertions(+), 51 deletions(-) > > > > diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst > > index b7695ddc59..0cc1349b9e 100644 > > --- a/docs/securityprocess.rst > > +++ b/docs/securityprocess.rst > > @@ -4,30 +4,28 @@ Security Process > > [...] > > > +Security concerns in libvirt should be reported as confidential issues in > > +the appropriate `project on GitLab. <https://gitlab.com/libvirt>`__. > > Should we perhaps add (e.g. as example) link to libvirt project itself > too for lazy clicks?
Yeah, that's probably a good idea. Worst case we can move bugs to other projects if desired, but chances are, almost all of them will be applying to libvirt.git > > [...] > > > +Publication embargo policy > > +-------------------------- > > [...] > > > > > +The libvirt project policy is to limit the time that a disclosure has the > > +"*confidential*" marker applied strictly to the minimum required to develop > > +and publish a suitable patch and allocate a CVE. > > [...] > > > > > +Given the widespread use of AI/LLM based agents for security auditing, > > +as well as ongoing use of traditional fuzzing and static analysis > > +tools, the QEMU maintainers consider that any disclosure originatinga > > s/QEMU/libvirt/ > > > +from automated tools is highly likely to be independently re-discovered, > > +potentially many times over in a very short timeframe. > > > > -Publication embargo policy > > --------------------------- > > +Thus the QEMU maintainers will generally reject requests for arbitrary > > s/QEMU/libvirt/ </face-palm> guess where I copy & pasted from :-) > > > +embargoes unless high severity, extenuating circumstances can be > > +demonstrated. > > Reviewed-by: Peter Krempa <[email protected]> > With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
