I'm looking for good information about how people actually *use* 
audit-packages to secure their systems, and more generally, how people 
use pkgsrc. What process do you follow when audit-packages reports a 
vulnerable package is installed? What advice would you give to someone 
planning to use pkgsrc packages on a few dozen machines with diverse 
configurations?

The audit-packages manpage doesn't give any hints, but the README.html 
for every single package says the following:

> If you have a vulnerable package installed on any machine, you are 
> advised to remove the package immediately, using the standard package 
> tools. The audit-packages package locates any installed package which 
> has been mentioned in security advisories as being vulnerable.

Remove the package? Sure, might as well unplug the machine and go hide 
out in the woods while we're at it. Assume we still need to have the 
package installed, and the only reason to remove it would be to replace 
it immediately with a non-vulnerable version.

Clearly the right thing to do, if I read the advisory and determine the 
vulnerability is significant in my environment, would be to upgrade the 
package to a non-vulnerable version. But then, what's the best way to 
do that? And, for vulnerabilities I want to ignore, is it worth 
configuring audit-packages to actually ignore them?

Suppose I wanted to use binary packages from ftp.netbsd.org; I'm 
looking at 
ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD-3.0/i386/lang/, and 
there's no php package available. Why? Well, it's been marked as 
vulnerable and moved to ../vulnerable/ instead. If I get the vulnerable 
package and install it, or I installed it before it was marked 
vulnerable, duh, audit-packages is going to complain, and I have a 
vulnerable system now. Can I assume a new, non-vulnerable binary 
package for php will ever appear in the lang directory, or is it 
impractical to depend on these binary packages?

If I'd rather build from source, is it better to keep a pkgsrc tree on 
every machine, or to designate a build machine and have it produce 
binary packages for all the other machines? I'm tempted to dismiss the 
option of pkgsrc on every machine, just because it would mean 
recompiling on every machine when audit-packages finds something in a 
commonly used package. But a single build machine might need to produce 
conflicting packages in order to cover all the possible configurations 
in a real environment (in which case, I could try to uninstall each 
package from the build machine after 'make package' succeeds, or keep 
multiple package databases and install destinations, or hope the 
pkgviews feature is mature enough to support all the packages I need).

But anyway, when audit-packages finds something, and there's a newer 
version of the package available in CVS, is it generally advisable to 
just do a cvs update on the existing pkgsrc tree and fiddle with it 
until 'make package' succeeds for each formerly vulnerable package and 
its potentially new dependencies? Is it better to set up a new pkgsrc 
tree (or mount_union a new directory on top of the old one) instead of 
updating in place? Is it better to try to update only the one package, 
either by a more narrowly focused cvs update, or by manually hacking 
the existing pkgsrc to fetch and build a newer version of the upstream 
software?

Or, as I've often wound up doing, building the new upstream software 
manually, outside of pkgsrc... I'd like to avoid doing that in the 
future, because audit-packages won't help me with manually installed 
software. Not to mention it's exactly the kind of tedium that pkgsrc is 
supposed to relieve (or, well, displace to the pkgsrc maintainers, I 
guess).

So, what do people generally find useful to deal with vulnerable 
packages?

	Thanks,
	  Robby