On Thu, May 21, 2026 at 3:07 PM Daniel P. Berrangé <[email protected]> wrote:
>
> 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 <[email protected]> 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.

Pedro, Yogesh, can you help answer Daniel's questions?

Thanks,

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

-- 
Mauro Matteo Cascella
Red Hat Product Security
PGP-Key ID: BB3410B0


Reply via email to