Subject: Re: pkg_delete "Executing" output
To: Alistair Crooks <agc@pkgsrc.org>
From: Todd Vierling <tv@duh.org>
List: tech-pkg
Date: 02/10/2005 11:45:42
On Thu, 10 Feb 2005, Alistair Crooks wrote:

> > > I don't understand your logic.  Just because you are presented with a
> > > lot of information, does that make the information itself useless?
> >
> > Yes.
>
> No.  It doesn't make the information useless at all.  I understand and
> accept that you think that TMI devalues the interpretation of that
> information itself, but overstating your case will not help.

No, it has to do with the quantity/scalability problem with garbage
information obscuring operationally impacting information.  To wit:

> > There's little chance of seeing real errors in the midst of all the
> > "successfully" executed commands.  Much less actually important messages
> > displayed by pkginstall's DEINSTALL about important system maintenance tasks
> > for the admin.

*This* is the crux of the problem.

> > There's a reason why, if nothing notable happened, NetBSD's /etc/security
> > script outputs nothing at all.

> /etc/security is completely different.  Given that there is already
> output from pkg_add and pkg_delete about package matching, about OS
> mismatching,

Ah, but these warnings from pkg_* are real operational warnings that could
have real runtime impact.  I want to see the operational warnings, because
they really could cause Bad Things to happen on my system, and I don't want
them obscured by otherwise useless messages scrolling them right off the top
of the screen in a flood of logs about otherwise "normal" operations.

It doesn't matter if we deliberately trojan packages right now just to make
the security point.  Users still won't read the "Executing ..." messages
about trojan operations; they will just blissfully ignore the messages
anyway.  After all, they're "normal" package operations, since they appear
in just about every package, right?

Security considerations of @[un]exec should be approached by a more
security-centered approach, such as digital signatures.

> This change was made more than a month ago:

> but the objections are only starting to surface now.

That's because PKGTOOLS_REQD was bumped on 4-Feb, not 6-Jan.  Before that,
most folks likely didn't update pkg_install.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>