On Thu, 10 Feb 2005, Alistair Crooks wrote:

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

Which is good to have, but not entirely useful for everyone.  An admin
interactively pkg_add'ing will probably want initial configuration notices
displayed immediately so they can be acted upon.

> But let's see what else is displayed at package build time

I didn't mention package build time.  I'm only talking about pkg_* tool
usage for binary packages, which has a slightly different target audience
(in the case of pkg_add, at least).

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

Right.  Such mismatches can be a very real problem, particularly if someone
mistakenly installs, for example, a NetBSD-current built package on 2.0.

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

It's really because valuable information -- like the OS mismatch warning and
messages dynamically appearing as part of pkginstall's duties -- is being
obscured.

> > > After all, they're "normal" package operations, since they appear
> > > in just about every package, right?
>
> Putting sweeping statements aside:

> that's about 10% of the packages in pkgsrc (my current bulk build has
> 5349 packages in total).

10% hit ratio is far more than enough to make a typical user classify these
messages as "normal" operations, fit to be ignored wholesale.  The fact that
larger packages, such as perl, use them more serves well to reinforce this
notion.

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

That's because no one has any clue how to use them, and for the most part,
few folks even know that such support exists at all.  The word "signature"
appears nowhere in the pkgsrc Guide.  I can't seem to find any docs on it
elsewhere, either; the most specific reference I can easily find is in a
USENIX 2004 PDF of a slideshow.

If there's already support, it should be documented in the Guide, including
whether they're detached signatures (and thus what filename the signature
should have), how to generate them, and how to know that the signature is
being verified.

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