Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jul 16, 2020 at 02:22:14PM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 16. Juli 2020 12:01:57 CEST Daniel P. Berrangé wrote:
> > > My concern here is that just distinguishing between either 'low' or 'high'
> > > is a far too rough classification.
> > > 
> > > In our preceding communication regarding 9pfs, I made clear that a) we do
> > > care about security relevant 9pfs issues, and only b) the avarage use
> > > cases (as far we know) for 9pfs are above a certain trust level.
> > > 
> > > However b) does not imply 9pfs being 'unsafe', nor that we want users to
> > > refrain using it in a security relevant environment. So 9pfs would
> > > actually be somewhere in between.
> > 
> > We shouldn't overthink this and invent many classification levels.
> > 
> > This is essentially about distinguishing code that is written with the
> > intent of protecting from a malicous guest, from code that assumes a
> > non-malicious guest. That is a pretty clear demarcation on when it is
> > reasonable to use any given feature in QEMU.
> > 
> > Within the set of code that is assuming a malicious guest, there are
> > still going to be varying levels of quality, and that is ok. We don't
> > need to express that programatically, the docs are still there to
> > describe the fine nuances of any given feature. We're just saying that
> > in general, this set of code is acceptable to use in combination with
> > a malicious guest, and if you find bugs we'll triage them as security
> > flaws.
> 
> Yes, that would be a base consideration for any security classification. And 
> it applies to 9pfs hence it would suggest 'high' for 9pfs, but ...
> 
> > 9p is generally written from the POV of protecting against a malicious
> > guest, so it would be considered part of the high security set, and
> > flaws will be treated as CVEs. We don't need to be break it down into
> > any more detail than that.
> 
> ... this is where it already differs from reality, as 9pfs security issues 
> were both handled as CVEs as well as normal reports for years, which nobody 
> objected.

Even if something is classified as "high", we still have the freedom to
decide whether each specific issue is worthy of a CVE or not.

> So I wonder how helpful it would be trying to either put 9pfs into either 
> 'high' or 'low', because another observed problematic with 9pfs is that the 
> degree of participation is so low, that if you try to impose certain formal 
> minimum requirements to contributors, you usually never hear from them again.
> 
> And BTW Prasad actually suggested the opposite classification: 

I don't personally mind whether 9p is classified high or low. It is really
upto the maintainers to decide which classification best fits. I'm just
saying that I think the simple binary choice is sufficient for our needs.

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