From owner-freebsd-vuxml@FreeBSD.ORG  Sun Aug 22 21:56:42 2004
Return-Path: <owner-freebsd-vuxml@FreeBSD.ORG>
Delivered-To: freebsd-vuxml@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5058F16A4CE; Sun, 22 Aug 2004 21:56:42 +0000 (GMT)
Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de
	[212.202.50.15])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id D780143D53; Sun, 22 Aug 2004 21:56:41 +0000 (GMT)
	(envelope-from eikemeier@fillmore-labs.com)
Received: from dhcp-8.local ([172.16.0.8] helo=dhcp-10.local)
	by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.41 (FreeBSD))
	id 1Bz0KN-000MQc-Il; Sun, 22 Aug 2004 23:56:41 +0200
Date: Sun, 22 Aug 2004 23:56:42 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
To: "Jacques A. Vidrine" <nectar@FreeBSD.org>
From: Oliver Eikemeier <eikemeier@fillmore-labs.com>
In-Reply-To: <20040822213232.GE17478@madman.celabo.org>
Message-Id: <272AEBD2-F486-11D8-8CAA-00039312D914@fillmore-labs.com>
Content-Transfer-Encoding: 7bit
User-Agent: KMail/1.5.9
cc: freebsd-vuxml@FreeBSD.org
cc: Tom Rhodes <trhodes@FreeBSD.org>
Subject: making <description> optional [Was: cvs commit:
	ports/security/portaudit-db/database portaudit.txt portaudit.xlist
	portaudit.xml]
X-BeenThere: freebsd-vuxml@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Documenting security issues in VuXML <freebsd-vuxml.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-vuxml>,
	<mailto:freebsd-vuxml-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-vuxml>
List-Post: <mailto:freebsd-vuxml@freebsd.org>
List-Help: <mailto:freebsd-vuxml-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-vuxml>,
	<mailto:freebsd-vuxml-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Aug 2004 21:56:42 -0000

Jacques A. Vidrine wrote:

> On Tue, Aug 17, 2004 at 12:58:47PM -0500, Jacques A. Vidrine wrote:
>> [Moving to freebsd-vuxml ... oh how I wish Bcc worked so that people on
>>  the other list knew where this went :-) ]
>>
>> On Tue, Aug 17, 2004 at 07:46:16PM +0200, Oliver Eikemeier wrote:
>>> When you can live with the dummy text produced by my perl script
>>> ("Please contact the FreeBSD Security Team for more information.") and
>>> we can make the `discovered' entry optional, fine with me. I can write
>>> a `make entry' perl script that parses a form an generates a template
>>> entry, send-pr like.
>>
>> FWIW, this sounds fine by me, except about the <discovered> part.
>> I see your point about it though... it may be dangerous to have a
>> bogus value (like the date of entry), because it may not get corrected
>> later.  But I don't want it optional, so that it is not forgotten.
>> Perhaps we need the possiblity of marking something explicitly
>> <unspecified> for such occassions ...
>
> OK, so this has been in the back of my mind for the past few days, and
> I feel pretty strongly about requiring certain portions of the VuXML
> entry.  During the development of the DTD, it was basically decided
> that in order to be useful, each entry *must* provide the following
> information:
>
> (I'm repeating some of what is in the DTD in English prose here :-)
>
>   - A "one-liner" <topic>
>   - What is <affected>.  (If nothing is affected, it shouldn't be
>     included.)
>   - A brief or even incredibly rich <description> of the problem,
>     including details specific to the particular packaging system or
>     vendor.  Quotes of other security advisories are fine.
>   - At least one entry in <references>.  It is highly recommended that
>     a CVE name be included, but this is not always possible.  There
>     should certainly at least be a public email or source file to
>     which to point.
>   - The date the issue was first disclosed (this was possibly
>     mis-named <discovery>).
>   - The <entry> date of this issue into the document
>
> So in this thread and another, Oliver has requested that <discovery>
> and <description> be made optional.  I understand that this is due to
> a desire to be able to make "quick" entries.  But I have to wonder,
> how does this really help?  I feel very strongly that a <description>
> must be required.  If one cannot provide even a quote from some other
> source, then one has not properly researched the issue.  It *is*
> possible, of course, to specify a description like
>
>   <description>
>     <body xmlns="http://www.w3.org/1999/xhtml">
>       <p>Description not yet available.</p>
>     </body>
>   </description>
>
> or even
>
>   <description>
>     <body xmlns="http://www.w3.org/1999/xhtml"><p /></body>
>   </description>
>
> and still have a valid VuXML document, but this is certainly not
> within the spirit of even "quick" documentation.  So, as an editor, I
> wouldn't prohibit such entries, just frown on them :-) I mean, if one
> has the single reference required, then one certainly has something to
> quote.

60 (in words: sixty) entries in portaudit have the description `Please 
contact the FreeBSD Security Team for more information'. There are 
references, so when you care to add a quote, feel free, in fact this 
might be a job for the security team. You can frown on them as often as 
you like, the question is whether you just want to have an optional 
<description> entry as an easy to spot sign that an editor is needed, or 
if you prefer to search for <p/> and similar constructs.

> I feel less strongly about the <discovery> element (as mentioned in
> my earlier message quoted above).  But still, after reflection I do
> not think that it should be optional.  I routinely set this to be the
> earliest public notice that I've found when looking for references.  I
> have never felt that it was difficult to decide.  In my case, I have
> to be a little more careful because I don't want to include a date
> earlier than any public reference (even if I was included in private
> discussion many weeks earlier).  But most people don't have to deal
> with that issue.  Finally, if an earlier reference eventually turns
> up, the <discovery> date can be modified, no big deal.
>
> However, I must admit that I have some doubt the value of the
> <discovery> date in any case.  What I'd really like to hear are some
> arguments for keeping it or getting rid of it!  I think it is useful
> information of itself to many reading VuXML content, and that combined
> with <entry> it provides a good metric about our response time.  But I
> could be overestimating the value of it, and if it somehow puts people
> off to need to provide this information, then maybe it loses.

Oviously we have a different opinion what is useful here. I expect most 
users to be simple consumers, not security researchers. They need 
information about the serverity of a vulnerability, and maybe 
remote/local exploitability, whoever cares about the discovery date 
could check the references. Often I find the discovery date 
entertaining, but not useful.

-Oliver