From owner-freebsd-vuxml@FreeBSD.ORG  Sun Aug 22 21:32:56 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 63E2B16A53D; Sun, 22 Aug 2004 21:32:55 +0000 (GMT)
Received: from gw.celabo.org (gw.celabo.org [208.42.49.153])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id C766143D1F; Sun, 22 Aug 2004 21:32:54 +0000 (GMT)
	(envelope-from nectar@celabo.org)
Received: from localhost (localhost [127.0.0.1])
	by gw.celabo.org (Postfix) with ESMTP
	id 403A55486E; Sun, 22 Aug 2004 16:32:54 -0500 (CDT)
Received: from gw.celabo.org ([127.0.0.1])
 by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024)
 with SMTP id 16323-01; Sun, 22 Aug 2004 16:32:42 -0500 (CDT)
Received: from madman.celabo.org (madman.celabo.org [10.0.1.111])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified))
	by gw.celabo.org (Postfix) with ESMTP
	id 6D0C354861; Sun, 22 Aug 2004 16:32:42 -0500 (CDT)
Received: by madman.celabo.org (Postfix, from userid 1001)
	id 1511D6D468; Sun, 22 Aug 2004 16:32:33 -0500 (CDT)
Date: Sun, 22 Aug 2004 16:32:32 -0500
From: "Jacques A. Vidrine" <nectar@FreeBSD.org>
To: Oliver Eikemeier <eikemeier@fillmore-labs.com>,
	Tom Rhodes <trhodes@FreeBSD.org>, freebsd-vuxml@FreeBSD.org
Message-ID: <20040822213232.GE17478@madman.celabo.org>
Mail-Followup-To: "Jacques A. Vidrine" <nectar@FreeBSD.org>,
	Oliver Eikemeier <eikemeier@fillmore-labs.com>,
	Tom Rhodes <trhodes@FreeBSD.org>, freebsd-vuxml@FreeBSD.org
References: <20040817122453.05edaaea@localhost>
	<56FC3488-F075-11D8-924A-00039312D914@fillmore-labs.com>
	<20040817175847.GC43426@madman.celabo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040817175847.GC43426@madman.celabo.org>
X-Url: http://www.celabo.org/
User-Agent: Mutt/1.5.6i
Subject: Re: 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:32:57 -0000

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.


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.

Cheers,
-- 
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org