On Thu, Feb 10, 2005 at 05:55:28PM +0100, Juan RP wrote:
> On Thu, 10 Feb 2005 11:45:42 -0500 (EST)
> Todd Vierling <tv@duh.org> wrote:
> 
> > 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.

Your objection is one that I can understand - TMI devalues the other
information which is printed. I accept that that is the case for a lot
of people. Indeed, it was the reason that I implemented the mailing of
the MESSAGE file at package install time.

But let's see what else is displayed at package build time - all of
the configuration information, all the build information.  I don't see
calls for it to be sent to /dev/null, because it is devaluing the
valuable administrative information.

There have been no calls to remove the "mismatched OS version" warnings
in the addition or deletion, or to make them only visible with a verbose
switch.

And yet you wish all calls to commands (which are executed as root
normally) to be covered up.  Is this not really an innate
conservatism, a resistance to change?  Or is it really because
valuable information is being obscured?  [This is a genuine question,
because I'm obviously out of step with the majority of opinions
expressed very forcefully here - agc]

> > 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?

Putting sweeping statements aside:

[17:11:53] agc@sys3 /usr/pkgsrc 120 > grep -l '@.*exec' */*/PLIST* | wc -l
     538
[17:13:19] agc@sys3 /usr/pkgsrc 121 >

That may not catch the auto-generated perl package PLISTs - I have
absolutely no idea whether they generate '@{,un}exec' entries - but
that's about 10% of the packages in pkgsrc (my current bulk build has
5349 packages in total).

This is completely tangential, but the PLIST is the wrong place for
these commands - they should be in the INSTALL and DEINSTALL files.
But I'll address this some other time.

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

Every time I have talked about digital signatures to people, they have
said what a good idea it would be if pkgsrc could support them, or
requests to show them documentation.  Now I admit that I chose the
wrong time to add them (September 2001), but it's done, they're there,
and they could easily be used.  It's just that no-one uses them.  I
have absolutely no idea why.
 
> I agree with Todd, those messages should be displayed with a verbose flag not
> without it and enabled by default.

OK, noted, but can you elaborate why you don't like them, please?

Thanks,
Alistair