All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Mauro Matteo Cascella <mcascell@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Pierrick Bouvier" <pierrick.bouvier@oss.qualcomm.com>,
	qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>
Subject: Re: RFC: GitLab issues for security disclosures
Date: Thu, 21 May 2026 14:06:52 +0100	[thread overview]
Message-ID: <ag8DbJqLzvTlJRIe@redhat.com> (raw)
In-Reply-To: <CAA8xKjWoMYBPedC5RP96=TOe2MzDwtsmBHFW=0Bq170YNsR9DQ@mail.gmail.com>

On Thu, May 21, 2026 at 02:45:08PM +0200, Mauro Matteo Cascella wrote:
> On Thu, May 21, 2026 at 1:14 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > something I was unaware of previously, is that gitlab is a CNA:
> > https://about.gitlab.com/security/cve/
> >
> > so using gitlab issues means assigning CVE #s should be super easy.
> 
> Red Hat is a CNA too, QEMU CVEs are currently being reserved by Red Hat.
> 
> In fact, Red Hat is a root CNA:
> https://www.cve.org/Media/News/item/blog/2023/01/10/Why-Red-Hat-Became-Root
> 
> Projects like glibc, postgresql and curl now operate as independent
> CNAs under Red Hat, retaining complete end-to-end ownership over CVE
> assignment. Is it time for QEMU to follow suit?

Is there any guidance on the process & implications of taking that
route, specifically as an OSS project ?

I've found this:

  https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/guides/becoming-a-cna-as-an-open-source-org-or-project.md

And there are obligations/requirements there which I would not be
very comfortable with agreeing to with my QEMU hat on.

 * CNA must provide a phone number for the primary POC.

I'm guessing the phone number is intended for someone/org to escalate
urgent issues ?

Related to this I see

 * CNA either should or must publish CVE Records within 24 hours
   of publication of a CVE ID.

and similarly in

  https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_2_sub_cnas

   "3.2.2.2 The administrative POC MUST include both email
    addresses and phone numbers and MAY include additional
    contact methods."
    
   "3.2.2.5 The administrative POC MUST respond in a timely manner.
    Automated responses do not qualify as “a timely manner.”"

As a co-operative volunteer project, my view is that we do not owe
anyone a guranteed or timely response. Yes, many of us are employed
by vendors to work on QEMU, but our work in the upstream community
context is still on a best effort basis. 

If someone requires an urgent or guaranteed response, whether to a CVE
or any other kind of issue, then the obligation needs to fall on the
paid vendors who distribute QEMU rather than any individual upstream
maintainers.

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 :|



  reply	other threads:[~2026-05-21 13:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 14:26 RFC: GitLab issues for security disclosures Daniel P. Berrangé
2026-05-19 15:18 ` Michael S. Tsirkin
2026-05-19 16:11   ` Daniel P. Berrangé
2026-05-19 16:19     ` Michael S. Tsirkin
2026-05-20 10:25 ` Mauro Matteo Cascella
2026-05-20 15:01 ` Pierrick Bouvier
2026-05-20 15:09   ` Daniel P. Berrangé
2026-05-20 17:33     ` Pierrick Bouvier
2026-05-20 17:39       ` Daniel P. Berrangé
2026-05-20 18:28         ` Warner Losh
2026-05-20 23:14         ` Michael S. Tsirkin
2026-05-21  9:06           ` Daniel P. Berrangé
2026-05-21 12:45           ` Mauro Matteo Cascella
2026-05-21 13:06             ` Daniel P. Berrangé [this message]
2026-05-21 13:17               ` Mauro Matteo Cascella
2026-05-21 11:09 ` Alex Bennée
2026-05-21 11:21 ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ag8DbJqLzvTlJRIe@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=mcascell@redhat.com \
    --cc=mst@redhat.com \
    --cc=pierrick.bouvier@oss.qualcomm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.