Re: New callhome(8) page; comments?

[Soren Jacobsen <snj%pobox.com@localhost>]

On Jan 24, 2010, at 2:18 PM, Martin Husemann wrote:

> On Sun, Jan 24, 2010 at 10:10:25PM +0000, Julio Merino wrote:
>> The point with this page is to document, in a centralized place, all
>> components that require access to external systems to work and for
>> which knowing which servers are accessed or what data is sent is
>> unclear.
> 
> I'm not sure this makes any sense at all.

I'm not sure it does either.  It would if we had any services that "called 
home" by default, but the consensus seems to be that we do not want anything 
like that.  So given that the user has to approve running any of these 
services, it's up to them to make an informed decision.  Matthew Mondor's post 
shows that this is a slippery slope.  I think this man page is unnecessary as 
long as it's clear from the rest of the documentation that these services 
access external systems.

Additionally, I'm not sure why a user would be looking for a man page of this 
type.  I'd think that one would be interested in a specific service, and while 
reading about that service be alerted to the fact that enabling it will result 
in contacting external systems (if it's not blindingly obvious from the nature 
of the service in the first place).  This would be different if we had such 
services running by default, but this is not the case.  So looking at 
pkg_admin(1), it does seem like there's a  bit of room for improvement, in that 
the description of fetch-pkg-vulnerabilities doesn't explicitly mention that 
the file is fetched over the network.  I think our users are smart enough to 
not need this spelled out, but if we're going to be paranoid about this sort of 
thing, pkg_admin(1) seems like the proper place to mention "calling home."

As a side note, it's really quite unfortunate that audit-packages and 
download-vulnerability-list have been deprecated and their man pages removed.  
Generally, when I'm looking for a command to do something, "man -k" is my first 
resort, and there's almost no way someone will find out about auditing packages 
in this manner.  One has to be reading pkg_admin(1), daily.conf(5), or 
security.conf(5) to stumble onto the documentation.  Sigh.