From nobody Mon Feb 9 17:24:14 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1646668852; cv=none; d=zohomail.com; s=zohoarc; b=NMa1vdGxPeQqrogZZxSXkh5NOj88Z+CZNJGA417UcpngIGrzI1Ehd4yU3DlwuwxROM/Rbh+bFPc/yQTgo5C54zm1zfeXO6Qj2oNEWtZS4xl5ZnCfJcTE8Sls2AKm2CqSH/OSR4bgvj6+LEj6UdTYaG3C4b5jVdCYiHs7vzRdnWs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1646668852; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=dRJTzigcIdl+iTvj9J2nxFNb08UsVRX5TGOYKxclF24=; b=ZDpSVrBEvX5bAmbwZcDVL3bZ056q2/hoJ0v5EuTCPpdAE1AjcMVV5kdAXVJ68k540omqKZ91pQgLUPNj1NUVdwP5pdmkxUbWdzNo65cLzzitXcO14rod3Yl0Aev9DWhjihNrbVKe7bwxbOpJ0v2ae/GCEu9JVjzeW6YGnxTtgkA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1646668852962715.244842609809; Mon, 7 Mar 2022 08:00:52 -0800 (PST) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-399-7WUff61pOS-mfi3mNottTA-1; Mon, 07 Mar 2022 11:00:23 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 75E451C05AF1; Mon, 7 Mar 2022 16:00:11 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 58886400E408; Mon, 7 Mar 2022 16:00:11 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 12511196BB81; Mon, 7 Mar 2022 16:00:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id AC13419305AE for ; Mon, 7 Mar 2022 16:00:08 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 805DA7D3CE; Mon, 7 Mar 2022 16:00:08 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.40.208.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id D38B58276B for ; Mon, 7 Mar 2022 16:00:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646668852; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=dRJTzigcIdl+iTvj9J2nxFNb08UsVRX5TGOYKxclF24=; b=FNUPEE6V6h6bMPd0Q+PQOgudJTuTtlVBQ5x6fWCyJIOkj3XXd+WvRJTRKPy19xyo9aZCgN Jj4dLTSHcKIbktXZzIIT8L11AE4Cdx530YzMJyYZrl2dn1nm9QThmZ46b7gVGH5OetVcW/ DkJOR1mxMLHZUJ1uY7RC7H1GrS4IScY= X-MC-Unique: 7WUff61pOS-mfi3mNottTA-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 10/17] docs: Convert 'securityprocess' page to rST Date: Mon, 7 Mar 2022 16:59:30 +0100 Message-Id: <3701671e3fa842d9be3e1194f190467781f84106.1646668723.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1646668856100100001 Content-Type: text/plain; charset="utf-8" Signed-off-by: Peter Krempa Reviewed-by: J=C3=A1n Tomko --- docs/meson.build | 2 +- docs/securityprocess.html.in | 119 ----------------------------------- docs/securityprocess.rst | 91 +++++++++++++++++++++++++++ 3 files changed, 92 insertions(+), 120 deletions(-) delete mode 100644 docs/securityprocess.html.in create mode 100644 docs/securityprocess.rst diff --git a/docs/meson.build b/docs/meson.build index b3432cc6f6..ab020ab090 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -61,7 +61,6 @@ docs_html_in_files =3D [ 'php', 'python', 'remote', - 'securityprocess', 'storage', 'testapi', 'testsuites', @@ -108,6 +107,7 @@ docs_rst_files =3D [ 'pci-addresses', 'platforms', 'programming-languages', + 'securityprocess', 'strategy', 'styleguide', 'submitting-patches', diff --git a/docs/securityprocess.html.in b/docs/securityprocess.html.in deleted file mode 100644 index 0e4802a1de..0000000000 --- a/docs/securityprocess.html.in +++ /dev/null @@ -1,119 +0,0 @@ - - - - - -

Security Process

- -
    - -

    - The libvirt project believes in responsible disclosure of - security problems, 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. -

    - -

    Reporting security issues

    - -

    - 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 details of - the problem as possible (ideally with steps to reproduce) - to the following email address: -

    - -
    -libvirt-security@redhat.com=
    
    - -

    - 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 indicating the report is held for - moderation. Postings by non-members will be approved by a - moderator and the reporter copied on any replies. -

    - -

    Security notices

    - -

    - Information for all historical security issues is maintained in - machine parsable format in the - libvi= rt-security-notice GIT repository and - published online - in text, HTML and XML formats. Security notices are published - on the libvirt-an= nounce mailing list - when any embargo is lifted, or as soon as triaged if already - public knowledge. -

    - -

    Security team

    - -

    - The libvirt security team is made up of a subset of the libvirt - core development team which covers the various distro maintainers - of libvirt, along with nominated security engineers representing - the various vendors who distribute 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 - embargo dates between vendors to allow simultaneous release of the - fix by all affected parties. -

    - -

    - 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 security address. Typically an existing - member of the security team will have to vouch for your credentials - before membership is approved. All members of the security team - are required to respect the embargo policy - described below. -

    - -

    Publication embargo policy

    - -

    - The libvirt security team operates a policy of - res= ponsible disclosure. - As such any security issue reported, that is not already publicly di= sclosed - elsewhere, will have an embargo date assigned. Members of the securi= ty 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 or less in duration. If a problem is identified - with a proposed patch for a security issue, requiring further - investigation and bug fixing, the embargo clock may be restarted. - In exceptional circumstances longer initial embargoes may be - negotiated by mutual agreement between members of the security - team and other relevant parties to the problem. Any such extended - embargoes will aim to be at most one month in duration. -

    - - -

    CVE allocation

    - -

    - The libvirt security team will associate each security issue with - a CVE number. The CVE numbers will usually be allocated by one of - the vendor security engineers on the security team. -

    - -

    Branch fixing policy

    - -

    - The libvirt community maintains one or more stable release branches - at any given point in time. The security team will aim to publish - fixes for GIT master (which will become the next major release) and - each currently maintained stable release branch. The distro maintain= ers - will be responsible for backporting the officially published fixes to - other release branches where applicable. -

    - - diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst new file mode 100644 index 0000000000..adddbf76b0 --- /dev/null +++ b/docs/securityprocess.rst @@ -0,0 +1,91 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Security Process +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. contents:: + +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. + +Reporting security issues +------------------------- + +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: + +:: + + libvirt-security@redhat.com + +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. + +Security notices +---------------- + +Information for all historical security issues is maintained in machine pa= rsable +format in the `libvirt-security-notice GIT +repository `__ and +`published online `__ in text, HTML and XML +formats. Security notices are published on the `libvirt-announce mailing +list `__ when any embargo is lifte= d, or +as soon as triaged if already public knowledge. + +Security team +------------- + +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. + +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. + +Publication embargo policy +-------------------------- + +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. + +CVE allocation +-------------- + +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. + +Branch fixing policy +-------------------- + +The libvirt community maintains one or more stable release branches at any= given +point in time. The security team will aim to publish fixes for GIT master = (which +will become the next major release) and each currently maintained stable r= elease +branch. The distro maintainers will be responsible for backporting the +officially published fixes to other release branches where applicable. --=20 2.35.1