qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU CII Best Practices record


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] QEMU CII Best Practices record
Date: Tue, 24 Oct 2017 08:42:03 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

On Mon, Oct 23, 2017 at 06:55:44PM +0100, Peter Maydell wrote:
> On 13 October 2017 at 14:25, Daniel P. Berrange <address@hidden> wrote:
> > Many projects these days are recording progress wrt CII best practices
> > for FLOOS projects. I filled out a record for QEMU:
> >
> >   https://bestpractices.coreinfrastructure.org/projects/1309
> >
> > I only looked at the 'Passing' criteria, not considered the 'Silver' and
> > 'Gold' criteria. So if anyone else wants to contribute, register an
> > account there and tell me the username whereupon I can add you as a
> > collaborator.
> 
> For the questions about "50% of bug reports must be acknowledged"
> and ditto enhancement requests, did you mine the launchpad data
> or are you just guessing? :-) Similarly for vulnerability report
> response time.

I didn't measure it, just used gut feeling. I see people like Thomas Huth
and David Gilbert in particular responding to many bugs which come in and
triaging existing bugs. So I think we're in the ballpark give or take 10%.

For vulnerability reports I think we get good response, between QEMU's secalert
team, and the distros security teams, we've got good coverage & response.

> I think you're fudging the test-policy questions in our favour a bit.

IMHO the way the CII website is setup with everyone self-certifying,
means it is largely a game. I view it is a way of identifying notable
gaps where we might consider improving our working practice, and as a
rough guide to outsides to understand our project, rather than a 100%
accurate reflection of what we do.

But if people think I've got something that is grossly inaccurate
please do point it out.



> >  -  The release notes MUST identify every publicly known vulnerability
> >     that is fixed in each new release.
> >
> >     I don't see a list of CVEs mentioned in our release Changelogs or
> >     indeed a historic list of CVEs anywhere even outside the release
> >     notes ?
> 
> Indeed I don't think we do this. I would say that as a project we
> essentially push the job of rolling new releases for CVEs, informing
> users about CVE fixes, etc, to our downstream distributors.

> I suspect we only pass the "no vulns unpatched for more than 60 days"
> if you allow "patched in bleeding edge master and in distros
> but not in any upstream release" to count.

I think patched in git master is sufficient to consider it a pass on the
criteria - they don't mention any specifics about having to maintain
multiple stable branches and backport.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]