On Thu, Feb 10, 2005 at 02:52:56PM -0500, Todd Vierling wrote:
> > > Right.  Such mismatches can be a very real problem, particularly if someone
> > > mistakenly installs, for example, a NetBSD-current built package on 2.0.
> >
> > So now OS mismatch is a valuable message, and yet commands which are
> > run as root on your behalf are not?
> 
> OS mismatch is a valuable message; that is a warning directed specifically
> at "me", the admin, about my decision to install the package and my
> operating environment in which it is installed.

I am not doubting that OS mismatch is a valuable message.  But I am
surprised that you consider it more important than what is being run
silently as root.
 
> If I'm running something as root (such as pkg_add or pkg_delete), I am
> accepting the consequences of commands run on my behalf.  To that end:

Yes, you were accepting the consequences. What I am saying is that I
don't like to be a victim, and I would like to take steps to at least
see what it's doing.
 
> > So the display of commands run as root is now making it so that you
> > can't view anything else?  I do find that hard to believe.
> 
> Try "pkg_delete -r perl" sometime; you might be surprised.  And try deleting
> *anything* managed under pkgviews; it generates @unexec's for every single
> directory in the package....

I do bulk builds all the time - I see binary package additions and
deletions come and go.  I'm familiar with package views as well.

The reason I added the display of commands being executed was so that
we wouldn't be surprised.
 
> If there's some kind of arbitrarily pressing need to display the fact that
> "things are running behind your back", perhaps we should take the SVR4
> approach, with only a one-liner about it by default (rather than one line
> per every specific command)?
> 
>     Running package @exec commands...
> 
> or similar.  Likewise, we could also have
> 
>     Running INSTALL script (phase PRE-INSTALL)...
> 
> which would give you the INSTALL/DEINSTALL audit point you want, without
> spewing loads of garbage all over the screen.  (Though distilling down to
> these one-liners should illustrate just how little value these notices
> really have.)

And here I will agree with you.  The message you are proposing to add
above - "Running package @exec commands" - adds nothing, gives no
information, and is quite useless.  You might as well display cowsay
with a "Today is the first day of the rest of your life" banner, or
"You don't have to be mad to work here, but it helps".
 
> Even in this case, a switch is needed to turn these messages off, because
> again, they're "normal" operations of pkg_add and pkg_delete.  An OS
> mismatch warning, by contrast, is not "normal".

That's not a real argument.  I could say "it's your fault for failing
to keep your binary packages under control", but it's not going to
endear me to many people, and I don't really consider it a viable
answer.  On the contrary, I want to see the warnings about OS
mismatches (and I do bulk builds on -current all the time, and
constantly see these warnings).  I also want to see what's taking
place silently, as root, on the computer in front of me.

I get enough of the "we know best, we'll run it for you" on Windows
boxes with ActiveX - having to run spyware scanners and immunisers is
a complete and utter PITA, and a complete waste of my time and money.

As to the normality of things, when do you consider it normal to
run a script as root and keep the person who invoked it unaware
that it is being executed?

> > > If there's already support, it should be documented in the Guide,
> 
> > We're getting off on a tangent here, but they are documented - see
> > pkg_add(1),
> 
> > I agree that the pkgsrc guide should have information on digital
> > signatures in it, although it tends to avoid mentioning binary package
> > addition, IIRC.
> 
> (...and this from one of the people who really Love the pkgsrc Guide(tm).
> <wide grin>)
> 
> Generation of signatures is a package *build time* operation, and filesystem
> management of signatures is out of band of pkg_add, so going to pkg_add(1)
> to figure out how to do that is a bit counterintuitive.

Unless it's been changed drastically since I implemented it,
generation of digital signatures can be done at any time at or after
binary package creation. 

If you want to add a package then pkg_add is the right tool for this. 
If the provenance of that package is given by a digital signature,
then pkg_add is still the right tool for this package addition.  Its
manual page describes the actions to be taken.  There is absolutely
nothing counterintuitive about this.
 
> And, of course, such signing should probably become part of a bulk build,
> but that's another discussion unto itself.

I agree, but the very nice people who do the bulk building will need
to be convinced of this fact, and they already give enough of their
time and resources by doing the bulk builds themselves.

And now for some sleep...

Alistair