Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:

> On Wed, 2005-10-26 at 19:41, Greg Troxel wrote:
>
> > I thing that the appropriate course is to log all such callbacks in
> > pkg-vulnerabilities, perhaps as 'home-callback' if it sends no
> > application data (and spyware if it does) and disable such callbacks
> > as bug fixes.  There could perhaps be an option to enable them.  By
> > default people should not be subjected to such behavior.
> 
> vulnerabilities might be one way to do it (but if you patch the package
> to not do this, it's not really "vulnerable" any more, is it?)

True; I meant to log a vulnerability when this is discovered, and
adjust the regexp when fixed.  

> ACCEPTABLE_BEHAVIORS += phone-home-during-{build,install,run} ?
> 
> we might want to distingush phone-home-during-build from
> phone-home-during-execution.

Sure, we could do that.  Qeustions arising:

  How many people want to enable this and will they do the work?

  Would such a variable effectively set a pkg option to add back in
  phone-home behavior?  Perhaps global options could suffice.  It's
  messy to allow build/install reporting; we'd have three sets of
  patches for some things.

> I agree that the default behavior should be to abort the build and not
> include the package in bulk binary builds, with a note explaining why.

If not fixed, this certainly seems appopriate.

I don't object to programs having an option to send a report when the
option is invoked; I don't think any of us are objecting to this, just
the automatic/unrequested information leaks.

> quietly patching the package to not do the call-home doesn't really do
> anything to discourage this behavior among package developers.

True, but there is the goal of providing pkgsrc users with a version
of software with all known security bugs fixed.

As a case study, I discovered that gabber (a gnome1 jabber client) had
phone-home behavior.  I contacted the author, and also sent a note to
bugtraq.

from pkg-vulnerabilities:
gabber<0.8.7nb4         privacy-leak	http://online.securityfocus.com/archive/1/307430

My recollection is that the leak was fixed in the gabber sources after
the bugtraq posting; it's not clear what would have happened w/o
sending to bugtraq.  It was patched in pkgsrc very quickly.

I share your concern about discouraging such behavior among package
authors.  I see the decision tree as

  1. don't fix, but mark as broken so a package can't be built accidentally

  2. fix the package via a patch, and as usual send the patch to upstream

    A. Perhaps send a note to a bugtraq-like forum, which helps
    non-pkgsrc users and fulfills part of the "discouraging such
    behavior" goal.

    B. Don't send to a bugtraq-like forum.

In my view, option 1 is a disservice to pkgsrc users.  2A is
appropriate for particuarly serious cases, and perhaps if the fix
isn't included in the upstread distribution.

-- 
        Greg Troxel <gdt@ir.bbn.com>