Subject: Re: Speeding up check-vulnerable
To: None <>
From: Roland Illig <>
List: tech-pkg
Date: 02/27/2005 12:21:28
Hubert Feyrer wrote:
> On Sat, 26 Feb 2005, Roland Illig wrote:
>> One point for discussion is clearly the naming. When you call
>>    $ pkg_admin vuln perl-5.8.6nb2 \
>>                /var/cache/distfiles/pkg-vulnerabilities
> First, I see no real gain in adding this to pkg_admin, as I think it's 
> rather uncommon to run this interactively. Waiting 5-15 seconds in the 
> daily output shouldn't hurt to add this to pkg_*. (I'm conservative 
> about breaking up the "combine tools" approach).

At least I sometimes want to know if a certain package is vulnerable, 
and if the current CVS version fixes that. But the main purpose of this 
pkg_admin extension is the non-interactive use in the pkgsrc build 
architecture, which happens really often. On my computer the 
check-vulnerable target needs 5 seconds (wall time), compared to 0.3 
seconds after the patch. This time is needed for every package that is 
built, as John noted in the other mail.

> Then, the syntax seems backwards. What you seem to want is to check one, 
> several, or all pkgs against a list of patterns, and see if it matches.

I already thought about swapping the order of the operands to be able to 
check multiple packages at one time. I will change the patch to do that.

> For a more generic approach, you want to have
>  * a list with patterns (only; easy to get, and doesn't hardcode the
>    format of the pkg-vulnerabilities file into pkg_admin).

No, I want exactly this behaviour. I need to give the user details 
(type, url) about the vulnerability instead of just saying:

*** WARNING: foopkg-1.5 contains some vulnerabilities. Good luck ***

The pkg-vulnerabilities file is the well-established format for pkgsrc 
to persistently save the vulnerabilities, so I use it.

>  * none, one or more packages or pkg patterns, that then get checked
>    against the list of patterns, and print all the names (not?) matching.
>    See the "pkg_admin check" syntax.

Well, I could distinguish human use and non-human use by a command line 
option. But I wrote it for the pkgsrc build system, where even the 
non-human use needs more that just the package name.