On 23/08/2016 11:08 PM, Weldon Godfrey wrote:
> Gerhard Schmidt <schm...@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
_______________________________________________
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
