From: "Daniel P. Berrange" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] QEMU CII Best Practices record
Date: Tue, 24 Oct 2017 08:42:03 +0100 [thread overview]
Message-ID: <20171024074203.GA24198@redhat.com> (raw)
In-Reply-To: <CAFEAcA9qtKi+hPTOBfZqZ97p=J+_3hmq-aNT8m-9ypKN-=+-AA@mail.gmail.com>
On Mon, Oct 23, 2017 at 06:55:44PM +0100, Peter Maydell wrote:
> On 13 October 2017 at 14:25, Daniel P. Berrange <berrange@redhat.com> 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 :|
next prev parent reply other threads:[~2017-10-24 7:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 13:25 [Qemu-devel] QEMU CII Best Practices record Daniel P. Berrange
2017-10-23 17:31 ` Stefan Hajnoczi
2017-10-23 17:55 ` Peter Maydell
2017-10-24 7:42 ` Daniel P. Berrange [this message]
2017-10-24 7:46 ` Daniel P. Berrange
2017-10-24 8:12 ` Peter Maydell
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=20171024074203.GA24198@redhat.com \
--to=berrange@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).