OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [was] Agenda for Thursday 25th

Hash: SHA1


I will try to participate today - let's see if it works overseas. ;o)
Sorry for my silence during the last weeks, but we are currently
setting up a very gainful project right now, that will last till December.

Some annotations regarding the "draft"
- - naming: please remove all non-alpha chars from the names.
  names containing blanks or other special characters are always problematic
  during data processing (normalization etc. pp.)
  "VulnDB's" or "Risk Ranking" are not acceptable
- - naming: please hold on to a strict naming convention, lets say
  all lowercase or java convention (starting with a lowercase char),
  e.g. "Risk Ranking" -> "riskRanking"
- - Remedy group: I don't think that a "Patch" is sufficient here. Most often
  the remedy does not consist of a simple patch, but of an abstract
  instruction. Thus the remedy should contain a textual description too.
- - ApplicableTo left out: I guess this is *the* criterion one would like to
  search for. The default scenario for me is: "I have got app server x and
  web server y on platform z, so what issues are known for that?"
  Everything else is only a refinement (e.g. "only those of the last month",
  "only the GPLd ones", etc.)
  So the applicableTo thing is a central point for retrieval.
  BTW the ApplicableTo as found in the current VulnXML DTD is one of
  the most over-worked things there: the cardinality and structure of the
  parts should be exactly what we need, so we could just adopt that part.
- - data entry stuff: I still dont understand why we should write yet another
  "skunkwork" editor to perform data entry based upon xml:schema while
  having a completely functional DTD based editor online that could be
  easily adapted.

As for the extension of the VulnXML execution logic:
I think it would be better to write a working executor based upon
what we have now as a proof-of-concept (the python based stuff
is rather outdated and I dont know, if someone is willing to adapt it)
before thinking of extensions. 

Let's discuss the the minutiae later on. :o)

Kind regards

Version: GnuPG v1.2.0 (GNU/Linux)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]