Subject: Re: Speeding up check-vulnerable
To: None <tech-pkg@NetBSD.org>
From: Roland Illig <roland.illig@gmx.de>
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.
Roland