cvs commit: ports/security/portaudit-db/database portaudit.txt
portaudit.xlist portaudit.xml
Jacques A. Vidrine
nectar at FreeBSD.org
Sun Aug 22 14:32:57 PDT 2004
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 at celabo.org / jvidrine at verio.net / nectar at freebsd.org
More information about the freebsd-vuxml
mailing list