Ports EOL vuxml entry

[Kubilay Kocak]

On 23/08/2016 11:08 PM, Weldon Godfrey wrote:
> Gerhard Schmidt <schmidt at ze.tum.de> wrote:
> 
>> Is an outdated (EOL) port a vulnerability? I don't think so. It's
>> a possible vulnerability, but not a real one.
> 
> An EOL product is typically no longer tracked, analyzed, and
> corrected for security vulnerabilities.  With this higher risk
> profile, it is correct to assume it is vulnerable or at least a
> higher security risk. Since a clean report from pkg audit with EOL
> packages on the system will mislead the vast majority of end-users
> that they have a lower risk security profile.  It is correct for pkg
> audit to warn on EOL packages. Especially since any actual
> vulnerabilities, that is almost certain to come up, will likely never
> show on a future report.

This (good) argument sounds primarily about classification and/or the
ability or lack thereof to distinguish between types-of-things, which
are not identical:

* Explicit vulnerability ("Active", Official record (CVE, etc), will or
likely/expected to be fixed)
* Implicit (probable) vulnerability (by way of EoL, no fixes/support,
may have CVE (forever), port/pkg deleted, etc)

VuXML is about declaring/documenting vulnerabilities yes, but it's also
about arming users with the information they need to make sound security
decisions. Being prescriptive in *either* case is not really telling the
full truth and feels unsatisfying.

If and when we delete ports/packages of still-upstream-supported
software (say they are BROKEN in latest FreeBSD versions) that have an
active CVE's now or ever in the future, are they "vulnerable" according
to what we want if a user has them installed? Should they be listed?

Having said that, VuXML is a 'vulnerability markup language', and
without an actual and explicit 'vulnerability', should it be listed?

On solutions, perhaps this is a simple matter of
--exclude-{deleted,eol,<type>} or similar in pkg audit to tell the
difference, allowing the user to make *note* of differences, and decide
accordingly. I shall avoid the bikeshed on what the default should be.

Or maybe an EoLXML. Read this generically as: a second or multiple data
'sources' for pkg audit, for auditing different things. Just free
thinking here.

./koobs