From owner-freebsd-vuxml@FreeBSD.ORG Tue Aug 17 19:16:48 2004 Return-Path: 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 CAA1B16A4CE for ; Tue, 17 Aug 2004 19:16:48 +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 77A5F43D39 for ; Tue, 17 Aug 2004 19:16:48 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-10.local ([172.16.0.10] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bx9Rt-000Bif-2U for FreeBSD-vuxml@FreeBSD.org; Tue, 17 Aug 2004 21:16:47 +0200 Date: Tue, 17 Aug 2004 21:18:33 +0200 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Oliver Eikemeier To: FreeBSD-vuxml@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: <3AF421B2-F082-11D8-924A-00039312D914@fillmore-labs.com> User-Agent: KMail/1.5.9 Subject: portaudit wishlist X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2004 19:16:48 -0000 Ok, things that I think would be really useful (incomplete list): - csh-style braces. When this is not the right syntax, this could be done with ja-bugzilla or ja-kr-cups but we have many slave ports which just differ in prefixes/suffixes, and it would be easy to expand them when reading the file. Yes, portaudit does linear searches. Besides, this will greatly diminish the size of the database. I'm even willing to sacrifice glob patterns `*' and `?' for that, although they can be quite convenient sometimes. - 1.* notation as the `smallest 1.x version possible'. 1.a is not the smallest, besides it is not completely transparent why .a is chosen in the range. When the `*' is the problem, this could be easily changed to a random character, or even a (greater equal range) tag (ok, the name is silly), but I want to have some standard way like >= 1.* < 2.* to match all 1.x and nothing else. No, I don't think >= 1.a < 2.a is good here. - make `discovery' optional. It's a nice-to-have, but sometimes hard to find out, and dummy entries like entry = discovery do not help anyone. (ok, superseeded by another thread). - make `description' optional. It is in the way of `quick' entries which should be researched later. Of course it is acceptable to fill it with a dummy value, but in this case it shouldn't be present IMHO and the dummy value should be provided by the rendering code. Or will an empty tag do? - make a `severity' field available. Of course it might be inaccurate, and software might want to ignore it and provide it's own data. Yet it is useful when you only have time for a quick glance (notify me immediately of severe vulnerabilities, all others should only appear in fridays report). It is a valuable guidance for the users, although I'm aware it is very error-prone. - add a classification into remote/local exploitable - add a `fixed' field that lists a version where the vulnerability is fixed. This could be used for a recommendation message, like "upgrade to version xxx" or "no upgrade is available, please deinstall the port or proceed with caution". This could also realized as an alternate tag. - Also we should add tags for the most popular references. Speaking of references, I would prefer something like CVS Multiple Vulnerabilities, which means they canbe rendered with a meaningful line (but most not, so is legal too). Ok, too many threads now. I have too look into this a little closer. -Oliver