For general information about VuXML see the VuXML web site and the FreeBSD Security pages.

FreeBSD VuXML Tools

This section contains various tools which can help in working with VuXML.

Makefile support for adding new entries

This patch for the VuXML port makes it simpler to add a new VuXML entry: vuxml-newvuln-makesupport.patch.


vxcheck is a small script to help check if a VuXML entry matches the apropriate package versions. The security/vxquery port must be installed and a recent package version file available. Typical use to check the most recent entry in the VuXML database is:

vxcheck -R -i portname


Convert an obfuscated message id into a normal message id. E.g. <IDSERV04FVjCRGryWtI0000000f () exchange ! idefense ! com> to conv-marc.


Convert a VuXML vid in some form into a proper URL reference. E.g. to conv-vidurl.

Package names

List of package names from the last couple of years can be found at: This file updated at intervals by Jacques A. Vidrine.

Sample crontab entry to keep a local copy of package-names up-to-date. This should be written one long line.

12 2 * * * * cd /a/files/FreeBSD && fetch -q -m && rm package-names.txt && bunzip2 -k package-names.txt.bz2

FreeBSD VuXML Notes

This section contains various notes about VuXML. They will be documented in the FreeBSD documentation more coherently later. Most notes are from comments made by Jacques A. Vidrine abut VuXML.

CVE names must be "spelled out" completely, i.e. this should be CAN-2004-0700.

Generally use MARC for mailing lists -

Use <mlist> for URL's pointing to mailing lists.

VuXML topic

Another style nit: the <topic> element content is free form, but as you've noticed I have been conventionally using a format of one word followed by a poor-man's em-dash followed by a short description. I generally make that first, single word match the port's directory name, which is generally all lowercase. But this is just a rule of thumb: for some things it doesn't quite work out. For example, some issue affect lots of ports like libXpm or Mozilla.

Modification date

My rule of thumb is something like: if it is a change that is important to notify users about, then we should add/bump the modified date.

Handling of unmaintained ports

> BTW. the FreeBSD port hasn't been updated and there is no maintainer... Do you have any procedure for handling those case?

Not really. If it is anything important, I do the update myself. But, I think it might be advisable to take an approach like this for ports without a maintainer:

  1. Document the issue
  2. If the security issue is ``serious'', mark the port FORBIDDEN referencing the issue
  3. Mark the port DEPRECATED 30 days out, referencing the issue

In other words, unmaintained ports with outstanding security issues should be deprecated. If someone fixes the issues, great! Even better if the port gets a new maintainer. I think that otherwise, the port is likely not to be fixed, especially for minor issues.


Hmm, let me think. I'm not trying to list every possible reference, which I think is pointless. I guess I'm trying to include all the *good* references :-) Things that make me believe that a reference is good:

  1. I define CVE names to be good :-)
  2. Original descriptions
  3. Clear descriptions
  4. Release announcements
  5. I prefer non-commercial references, e.g. versus; US-CERT versus Secunia; and so on. But this would never be the overriding factor for inclusion.
  6. Details such as where in the implementation the bug exists
  7. The source patch, or references that make it clear where to get a patch.

Port deprecation policy:

Things a vuxmllint could check for: