From nobody Tue Aug 4 22:19:41 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1785753083; cv=none; d=zohomail.com; s=zohoarc; b=KcoClHqXwnaFIkUV4UxbskMGKY4V3Xzt9Jym0wRBTd+Mj2RjeUqpo7xqFfE99jLeq4tstulRwceJf61yY0auj8VUdMSIGqu2BF9VL4XGru3NXrW6w7mp7AdymzamaiIKH1vtWJ6NHrvJoZDqGQPZJEw/JphpiexY3WKC/qAiiUE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1785753083; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id:Cc; bh=gyixdOS7gtg87dFbunT+BWxCESrCGUb4EiimRqWKCiY=; b=ZZTIxs4gGY0wtvlfRv9Fd8B0B2R/pgc2oQok3p9z1DqzHLJGbJb3/I9WKrWXvXiU61Kl0bl16x+rMW2CYZDiyI9qlIfkNI2bFnipH+RWdQAyT/PdGY0nJSkRXXuD3EFmki6dkYMfpUsfzdRV4uIFLrLhNS69pHCl+LOpAv7sfxk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1785753083298885.056990458695; Mon, 3 Aug 2026 03:31:23 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 9C6263F2F3; Mon, 3 Aug 2026 06:31:21 -0400 (EDT) Received: from [172.19.199.10] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 60C99418DF; Mon, 3 Aug 2026 06:29:27 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 687793FD39; Mon, 3 Aug 2026 06:29:16 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id E7D413FA2E for ; Mon, 3 Aug 2026 06:29:14 -0400 (EDT) Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-0KX66nA9MfWuE-35is9ctg-1; Mon, 03 Aug 2026 06:29:02 -0400 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 19B781956071 for ; Mon, 3 Aug 2026 10:29:02 +0000 (UTC) Received: from berrange.com (unknown [10.44.33.191]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0B7DF180044F; Mon, 3 Aug 2026 10:29:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, RCVD_IN_SBL_CSS,SPF_HELO_PASS autolearn=no autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785752954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gyixdOS7gtg87dFbunT+BWxCESrCGUb4EiimRqWKCiY=; b=P9RTyU6u8OkdRsZfChtHJ6YFDA3ui24RTVuSM9awFMjEwMEpyexXggZhJWahWUEusGbYQj pZptSwAUYxc+wf4YqIKOm7truvoWpmYTFuOG4Qqb+a3uEEDTLA9bVCUE2ZAWTqZaMSg4t6 MPEmaaPnT9sEQs5pZBXV5TEv47/X/nQ= X-MC-Unique: 0KX66nA9MfWuE-35is9ctg-1 X-Mimecast-MFC-AGG-ID: 0KX66nA9MfWuE-35is9ctg_1785752942 To: devel@lists.libvirt.org Subject: [PATCH] docs: switch to GitLab issue tracker for security disclosures Date: Mon, 3 Aug 2026 11:28:59 +0100 Message-ID: <20260803102859.1483733-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: wlTWpq2BhHy3Fl7wFXcWBqxK-x_rcOmuWnY9LYgFm5I_1785752942 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: IJ5I5CTDUXJF2QI4PA263RP7D4NOK2JF X-Message-ID-Hash: IJ5I5CTDUXJF2QI4PA263RP7D4NOK2JF X-MailFrom: berrange@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9_via_Devel?= Reply-To: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1785753085355158500 From: Daniel P. Berrang=C3=A9 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=C3=A9 Reviewed-by: Peter Krempa --- 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 =20 .. contents:: =20 -The libvirt project believes in responsible disclosure of security problem= s, to -allow vendors time to prepare and distribute patches for problems ahead of= their -publication. This page describes how the process works and how to report -potential security issues. +The libvirt project handles security disclosures with a lightweight process +whose aim is to minimize the overhead of triage and prioritize publication +of a patch that addresses the issue. =20 Reporting security issues ------------------------- =20 -In the event that a bug in libvirt is found which is believed to have -(potential) security implications there is a dedicated contact to which a = bug -report / notification should be directed. Send an email with as many detai= ls of -the problem as possible (ideally with steps to reproduce) to the following= email -address: +Security concerns in libvirt should be reported as confidential issues in +the appropriate `project on GitLab. `__. =20 -:: +Ensure that the "**turn on confidentiality**" checkbox is selected prior to +submitting the issue, to restrict visibility to project maintainers only. =20 - security@lists.libvirt.org +Maintainer(s) will analyse the reported disclosure and decide whether it +is to be classed as a security flaw or not. If not a security flaw, the +``confidential`` tag will be removed immediately. If a security flaw, +the maintainers will work to develop and test a patch. When a suitable +patch is considered ready to post to the mailing list or a merge request, +the ``confidential`` tag will be removed. Generally a CVE should be assignd +to a security issue before a patch is ready to be posted (see below). =20 -NB. while this email address is backed by a mailing list, it is invitation= only -and moderated for non-members. As such you will receive an auto-reply indi= cating -the report is held for moderation. Postings by non-members will be approve= d by a -moderator and the reporter copied on any replies. - -Refer to the `bug reporting `__ +Note: Refer to the `bug reporting `__ page for the *expectations around the use of automated tools and AI agents= *, **prior** to filing any security report. =20 @@ -42,48 +40,42 @@ formats. Security notices are published on the `libvirt= -announce mailing list `__ when any embargo is lifted, or as soon as triaged if already public knowledge. =20 -Security team -------------- +Publication embargo policy +-------------------------- =20 -The libvirt security team is made up of a subset of the libvirt core devel= opment -team which covers the various distro maintainers of libvirt, along with -nominated security engineers representing the various vendors who distribu= te -libvirt. The team is responsible for analysing incoming reports from users= to -identify whether a security problem exists and its severity. It then works= to -produce a fix for all official stable branches of libvirt and coordinate e= mbargo -dates between vendors to allow simultaneous release of the fix by all affe= cted -parties. +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. =20 -If you are a security representative of a vendor distributing libvirt and = would -like to join the security team, send an email to the afore-mentioned secur= ity -address. Typically an existing member of the security team will have to vo= uch -for your credentials before membership is approved. All members of the sec= urity -team are **required to respect the embargo policy** described below. +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 originating +from automated tools is highly likely to be independently re-discovered, +potentially many times over in a very short timeframe. =20 -Publication embargo policy --------------------------- +Thus the QEMU maintainers will generally reject requests for arbitrary +embargoes unless high severity, extenuating circumstances can be +demonstrated. =20 -The libvirt security team operates a policy of `responsible -disclosure `__. As s= uch -any security issue reported, that is not already publicly disclosed elsewh= ere, -will have an embargo date assigned. Members of the security team agree not= to -publicly disclose any details of the security issue until the embargo date -expires. - -The general aim of the team is to have embargo dates which are two weeks o= r less -in duration. If a problem is identified with a proposed patch for a securi= ty -issue, requiring further investigation and bug fixing, the embargo clock m= ay be -restarted. In exceptional circumstances longer initial embargoes may be -negotiated by mutual agreement between members of the security team and ot= her -relevant parties to the problem. Any such extended embargoes will aim to b= e at -most one month in duration. +If a patch for a confirmed security issue cannot be developed by a +maintainer in a reasonable time, the maintainers may choose to make +a disclosure public without having a patch available. This approach +should only be taken for issues judged to have low severity. =20 CVE allocation -------------- =20 -The libvirt security team will associate each security issue with a CVE nu= mber. -The CVE numbers will usually be allocated by one of the vendor security -engineers on the security team. +If a reported disclosure is confirmed to be a security flaw, the +``CVE::Required`` label will be added. + +When a CVE has been allocated, this label will be removd and replaced +by ``CVE::Assigned``. + +The allocated CVE identifier will be included in the patch(es) that +are required to fix the issue. If multiple patches are involved, the +CVE must be included in the final patch in the series that closes the +last hole, but should also be included in any prior patches it the +series that are directly related. =20 Branch fixing policy -------------------- --=20 2.55.0