Steven M. Bellovin responds to my query:

>> I have installed about 300 packages from source, based on 2005Q4
>> (and occasional updates to 2005Q4 since last December).  What does
>> it mean to me in practice that 2005Q4 has been deprecated?  Is it
>> expected that I would re-install all of my software every few
>> months? If not, how long will security patches continue to be made
>> on 2005Q4?  If I want an update to a particular package as found
>> in a more recent pkgsrc branch, is there a way that this update
>> can coexist peacefully with the rest of my installed software,
>> short of giving it a whole separate directory hierarchy?

> Pkgsrc usually does not contain security bug fixes, though there are
> exceptions.

Sure; I have "cvs update"d shortly after audit-packages reported a
problem, and found that the problematic package had had the "nb" part
of its version number updated, and that appropriate patches had been
made.  I have found this very helpful, though I admit that I have
often resorted to "make replace" to avoid unwanted recompilations and
updates.   :-/

> The problem is that dependencies change.

I understand that, and I can only imagine the complexity of keeping the
dependencies properly synched.

I think I may not have expressed my question clearly.  I'll try again,
at the risk of being verbose.

I've been using NetBSD on my home machine (well, a succession of
machines over the years) for about a decade, and still things happen
that make me realize that I don't completely understand the NetBSD
system administration model.  This is frustrating in view of the
fact that I've been a Unix sysadmin for 15 years now - that is, I
don't think the fault is entirely my lack of understanding.  I've
dealt in the past mainly with SunOS, early Solaris, Ultrix,
OSF1/Digital-Unix/Tru64, and a smattering of others such as MIPS
and Slackware Linux.  Where I currently work, servers are mostly
Solaris (7, 8, 9) and RHEL 3.

I may or may not think that those vendors are doing a good job
(some are doing a terrible job, especially in view of whay we pay
them!), but I feel I do understand what they expect me to do in
terms of keeping the system patched.  There is usually a system of
e-mailed alerts, and a way to apply needed patches.

With respect to NetBSD, the operating system, I'm happy with the
format of the recent security advisories: it's clear which systems
are affected, and what minimal change I need to make to get rid of
the problem (update such-and-such a file using this cvs command,
recompile and reinstall this package using that command, replace
the kernel, etc.).  The only improvement I could imagine would be
a program similar to "audit-packages", which would notify me of
which updates needed to be applied on a particular system, so that
I would not have to keep track myself.  But overall, for the O/S,
the alert+patch system works.

With respect to the pkg system, I'm not there yet.

> There are no great solutions here.  You can periodically refresh your
> entire /usr/pkg tree; if you're lucky, you can do the rebuilds via
> pkg_comp in a chrooted partition.  Or you can use pkg_chk to rebuild
> everything, or lintpkgsrc+pkgdepgraph to figure out what's out of
> date.  About 1 time in 3 that I try this, I find that *something* won't
> rebuild.

Your answer makes me suspect that either you're in the same position
as I am, or, perhaps, the system administration model for pkgsrc is
not well developed yet.  If we run audit-packages, as is recommended,
we get the alerts, and what's really nice is that we get alerted only
for actual vulnerable software that's installed.  So part 1 works
really well.

But part 2, what to do about a vulnerable package, is the part that
either I have not understood, or has not been fully solved.  It's
possible that the answer to it will be quite different from the answer
to the question of how I voluntarily upgrade a particular package (and
its dependency graph as needed) without trashing everything and
starting over.

I want to make it clear that it's not my intention to discourage
volunteers whose work I benefit from and whose expertise I admire;
on the contrary, you all have my gratitude.  This O/S and pkg get
better all the time, and the fact that I continue using it speaks
eloquently, I hope.

But I think that the mental model for the system administration of
pkgsrc needs to be reviewed, or perhaps simply communicated more
clearly (I'll be embarrassed if this is on a web page somewhere, but
if so, I haven't seen it yet).  In that spirit, I'd like to ask the
designers of the pkg system:

  (a) When audit-packages tells me that an installed package has a
      vulnerability, what actions do you recommend that I perform
      in reaction to that report?  (Each package's web page states "If
      you have a vulnerable package installed on any machine, you are
      advised to remove the package immediately" - which is not
      terrifically helpful in practice!)

  (b) When I want to upgrade a particular package (for example because
      I need its new functionality), how do you recommend that I do
      this, bearing in mind that I have a lot of other software
      installed and in use on the system?


Anne.
-- 
Ms. Anne Bennett, as a private citizen:  anne@porcupine.montreal.qc.ca
Also reachable more officially at work:  anne@encs.concordia.ca