From paulbeard@gmail.com  Wed Mar 27 16:17:14 2013
Return-Path: <paulbeard@gmail.com>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	by hub.freebsd.org (Postfix) with ESMTP id 5415E80C
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 27 Mar 2013 16:17:14 +0000 (UTC)
	(envelope-from paulbeard@gmail.com)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51])
	by mx1.freebsd.org (Postfix) with ESMTP id 339D3A81
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 27 Mar 2013 16:17:14 +0000 (UTC)
Received: by mail-pb0-f51.google.com with SMTP id rr4so2640515pbb.24
        for <FreeBSD-gnats-submit@freebsd.org>; Wed, 27 Mar 2013 09:17:08 -0700 (PDT)
Received: from mail.thistledew.org (c-67-161-86-33.hsd1.wa.comcast.net. [67.161.86.33])
        by mx.google.com with ESMTPS id hs8sm21973776pbc.27.2013.03.27.09.17.06
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Wed, 27 Mar 2013 09:17:07 -0700 (PDT)
Received: by mail.thistledew.org (Postfix, from userid 0)
	id E12F211585; Wed, 27 Mar 2013 09:17:04 -0700 (PDT)
Message-Id: <20130327161704.E12F211585@mail.thistledew.org>
Date: Wed, 27 Mar 2013 09:17:04 -0700 (PDT)
From: "Charlie &" <paulbeard@gmail.com>
Reply-To: paulbeard@gmail.com
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: postgrey has surfaced a bug in perl's taint checking
X-Send-Pr-Version: 3.113
X-GNATS-Notify: ports.maintainer@evilphi.com

>Number:         177416
>Category:       ports
>Synopsis:       mail/postgrey has surfaced a bug in perl's taint checking
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 27 16:20:00 UTC 2013
>Closed-Date:    Mon Apr 29 10:27:52 UTC 2013
>Last-Modified:  Sun Jun 23 06:30:02 UTC 2013
>Originator:     Charlie &
>Release:        FreeBSD 8.3-RELEASE i386
>Organization:
none
>Environment:
System: FreeBSD shuttle.paulbeard.org 8.3-RELEASE FreeBSD 8.3-RELEASE #3: Thu Aug 30 16:34:02 PDT 2012 root@shuttle.paulbeard.org:/usr/obj/usr/src/sys/SHUTTLE i386


	
>Description:
postgrey seems to have surfaced a bug in perl's taint checking. 

Running it as an rc script or in the service infrastructue doesn't reveal anything, it just silently exits, 
but on the commandline you get this:
postgrey --inet=10023 --pidfile=/var/run/postgrey.pid --user=postgrey --group=postgrey  --dbdir=/var/db/postgrey
2013/03/27-08:53:46 postgrey (type Net::Server::Multiplex) starting! pid(45305)
Resolved [localhost]:10023 to [::1]:10023, IPv6
Resolved [localhost]:10023 to [::1]:10023, IPv6
Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
Duplicate configuration (TCP) on [::1]:10023 with IPv6) - skipping
Duplicate configuration (TCP) on [127.0.0.1]:10023 with IPv4) - skipping
Binding to TCP port 10023 on host ::1 with IPv6
Insecure dependency in socket while running with -T switch at /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm line 80.

If you switch to domain socket, rather than a port, it will run but you can't daemonize it with the -d flag. 
You can use regular job control (fg/bg/ampersand) but that doesn't work very well at boot time. Your boot process 
may well hang waiting on the &. Or turn off taint checking in postgrey. 
>How-To-Repeat:
	just run as normal
>Fix:
no idea 
All perl modules have been rebuilt from source (deinstalled/reinstalled from fresh distfiles) as has perl itself. 
System has been rebooted. 
There are similar reports here: 
http://www.perlmonks.org/?node_id=363466 
http://forums.gentoo.org/viewtopic-t-954454.html?sid=c01c137a57d5751924610093a06980f8


	

If you switch to domain socket, rather than a port, it will run but you can't daemonize it with the -d flag. 
So, not ideal. Or turn off the -T option. Your call. 
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: edwin 
State-Changed-When: Wed Mar 27 23:50:19 UTC 2013 
State-Changed-Why:  
Awaiting maintainers feedback (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=177416 

From: Edwin Groothuis <edwin@FreeBSD.org>
To: ports.maintainer@evilphi.com
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Wed, 27 Mar 2013 23:50:18 UT

 Maintainer of mail/postgrey,
 
 Please note that PR ports/177416 has just been submitted.
 
 If it contains a patch for an upgrade, an enhancement or a bug fix
 you agree on, reply to this email stating that you approve the patch
 and a committer will take care of it.
 
 The full text of the PR can be found at:
     http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177416
 
 -- 
 Edwin Groothuis via the GNATS Auto Assign Tool
 edwin@FreeBSD.org

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: bug-followup@FreeBSD.org, paulbeard@gmail.com
Cc:  
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Thu, 28 Mar 2013 17:52:47 -0700

 I can't reproduce this.  I have postgrey in production on RELENG_8_3 and 
 RELENG_9_1 systems both i386 and amd64 and in all cases postgrey works 
 without error.  I've also tested all four combinations of inet/unix 
 foreground/daemonized on those systems and postgrey functioned normally. 
   The taint checker triggers on code in the base perl install itself, 
 not in postgrey code.
 
 Paul and I had a fairly extensive email exchange before he filed this 
 PR.  I believe Paul's perl install is broken in some way.  The only 
 other documented instances of the error I could find occur in *very* old 
 perl code.  Perhaps there are stale files or some other undetected 
 conflict among the over 600 perl modules he has installed.  There is 
 also this snippet from the email exchange which implies exactly this 
 scenario:
 
 > Strangely, I deleted that file and rebuilt the port that owns it, but
 > I still get a modification date from 2009:
 > May 13  2009 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm
 >
 > what do you get for this?
 > pkg_which /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 > Now that I have deleted it, pkgdb thinks it belongs to perl itself.
 
 To me this screams broken install, broken/corrupt ports and/or a damaged 
 package database.  After close to two decades of using perl, it wouldn't 
 surprise me at all if some module stomped on other base/module code and 
 a slightly broken or improperly linted port missed the conflict.  FWIW, 
 on all of my systems, even EOL'd ones, pkg/pkgng tells me that file is 
 owned by lang/perl5.14 and the timestamp is consistent with the last 
 time the port was installed.
 
 Postgrey is a network-enabled daemon.  Running with tainted-variable 
 checking enabled is best practice.  Postgrey itself has had taint-mode 
 enabled since 2005.  I'm not going to hang everyone's tails out in the 
 wind by disabling it by default.  I can't ethically support even a port 
 option to disable it given the circumstances of the error report.  If 
 Paul wants to disable taint-checking on his system, he can, of course, 
 remove the -T flag from the hashbang in the installed script.

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Thu, 28 Mar 2013 21:43:12 -0700

 On Mar 28, 2013, at 5:52 PM, Darren Pilgrim <ports.maintainer@evilphi.com> w=
 rote:
 
 > To me this screams broken install, broken/corrupt ports and/or a damaged p=
 ackage database.  After close to two decades of using perl, it wouldn't surp=
 rise me at all if some module stomped on other base/module code and a slight=
 ly broken or improperly linted port missed the conflict.  FWIW, on all of my=
  systems, even EOL'd ones, pkg/pkgng tells me that file is owned by lang/per=
 l5.14 and the timestamp is consistent with the last time the port was instal=
 led.
 >=20
 
 I have rebuilt/reinstalled the lot since then and get the same result. So th=
 at's not it. Unless the implication is that a new system could exhibit this b=
 ehavior.=20
 
 > Postgrey is a network-enabled daemon.  Running with tainted-variable check=
 ing enabled is best practice.  Postgrey itself has had taint-mode enabled si=
 nce 2005.  I'm not going to hang everyone's tails out in the wind by disabli=
 ng it by default.  I can't ethically support even a port option to disable i=
 t given the circumstances of the error report.  If Paul wants to disable tai=
 nt-checking on his system, he can, of course, remove the -T flag from the ha=
 shbang in the installed script.
 
 As noted, there are other instances of this reported though they are vanishi=
 ngly rare. So there may be something in the almost 20 year old code (some of=
  the modules have comment/copyright dates from the mid 90s) that only shows u=
 p under rare confluences of events.=20
 
 And to be clear, it's not the taint check alone: it's the fact that the daem=
 onize option no longer works. There's no runtime argument or config option f=
 or that. It just doesn't work at all. So running it as a service fails.=20
 
 As noted in the email thread that preceded the PR, this is moot, as my ISP j=
 ust killed inbound smtp service so postgrey isn't actually doing anything. I=
 f my perl fu was of any strength at all, I would have tried building a test c=
 ase that tested the socket, taint checking, and daemonize capabilities of th=
 is environment. So I can't even claim this is a show stopping bug unless I c=
 onvince my ISP that they're doing it wrong (blocking inbound while allowing o=
 utbound as a defense against spam/botnets is nonsense).=20
 
 I don't think this is a bug in postgrey which is why I worded the subject as=
  I did. I think the misfeature is in the modules or perhaps in some unique a=
 spect of my kernel/userland.=20=

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Thu, 28 Mar 2013 22:20:55 -0700

 On 2013-03-28 21:43, Paul Beard wrote:
 > I have rebuilt/reinstalled the lot since then and get the same
 > result. So that's not it. Unless the implication is that a new system
 > could exhibit this behavior.
 
 There are steps between what's been done so far and a brand new system. 
   A complete refetch and reinstall of everything perl is one such step.
 
 > As noted, there are other instances of this reported though they are
 > vanishingly rare.   So there may be something in the almost 20 year old
 > code (some of the modules have comment/copyright dates from the mid
 > 90s) that only shows up under rare confluences of events.
 
 That's more or less my point, yes.  You have about 5 times as many p5 
 ports as I've ever seen on one system.
 
 > And to be clear, it's not the taint check alone: it's the fact that
 > the daemonize option no longer works. There's no runtime argument or
 > config option for that. It just doesn't work at all. So running it as
 > a service fails.
 
 The thing is I can't reproduce this behaviour.  I even ran it on a 
 RELENG_6 system and it worked fine there.
 
 > I don't think this is a bug in postgrey which is why I worded the
 > subject as I did. I think the misfeature is in the modules or perhaps
 > in some unique aspect of my kernel/userland.
 
 But it's a PR for the mail/postgrey port.  It sounds like it's 
 reasonable to close this PR.
 

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Thu, 28 Mar 2013 23:08:22 -0700

 --Apple-Mail-BBBDAB24-12EB-4514-B60A-24C860CE312D
 Content-Type: text/plain;
 	charset=us-ascii
 Content-Transfer-Encoding: quoted-printable
 
 
 
 On Mar 28, 2013, at 10:20 PM, Darren Pilgrim <ports.maintainer@evilphi.com> w=
 rote:
 
 > There are steps between what's been done so far and a brand new system.  A=
  complete refetch and reinstall of everything perl is one such step.
 >=20
 
 Done. Still seeing it.=20
 >=20
 > That's more or less my point, yes.  You have about 5 times as many p5 port=
 s as I've ever seen on one system.
 >=20
 Hey, I don't ask for them, they're mostly dependencies called by other ports=
 . I could try removing them all and just installing postgrey and it's depend=
 encies but that never came up before now.=20
 
 >=20
 > The thing is I can't reproduce this behaviour.  I even ran it on a RELENG_=
 6 system and it worked fine there.
 
 And it worked fine here until, suspiciously, I lost port 25 service. Coincid=
 ence, I'm sure, but that's when I noticed it.=20
 
 >=20
 > But it's a PR for the mail/postgrey port.  It sounds like it's reasonable t=
 o close this PR.
 
 I have no idea what piece of code is balking, I just know what provokes it. H=
 ence the wording: "mail/postgrey has surfaced a bug in perl's taint checking=
 ."=20
 
 So close it. I was optimistic that filing a PR might get more than one pair o=
 f eyes looking at it, especially as the error wasn't in the port with which t=
 hey were associated.=20=
 
 --Apple-Mail-BBBDAB24-12EB-4514-B60A-24C860CE312D
 Content-Type: text/html;
 	charset=utf-8
 Content-Transfer-Encoding: quoted-printable
 
 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
 utf-8"></head><body dir=3D"auto"><div><br></div><div><br>On Mar 28, 2013, at=
  10:20 PM, Darren Pilgrim &lt;<a href=3D"mailto:ports.maintainer@evilphi.com=
 ">ports.maintainer@evilphi.com</a>&gt; wrote:<br><br></div><blockquote type=3D=
 "cite"><span>There are steps between what's been done so far and a brand new=
  system. &nbsp;A complete refetch and reinstall of everything perl is one su=
 ch step.</span><br><span></span><br></blockquote><div><br></div><div>Done. S=
 till seeing it.&nbsp;</div><blockquote type=3D"cite"><blockquote type=3D"cit=
 e"><div style=3D"display: none; "><br></div></blockquote><span></span><br><s=
 pan>That's more or less my point, yes. &nbsp;You have about 5 times as many p=
 5 ports as I've ever seen on one system.</span><br><span></span><br></blockq=
 uote>Hey, I don't ask for them, they're mostly dependencies called by other p=
 orts. I could try removing them all and just installing postgrey and it's de=
 pendencies but that never came up before now.&nbsp;<div><div><br><blockquote=
  type=3D"cite"><blockquote type=3D"cite"><div style=3D"display: none; "><br>=
 </div></blockquote><span></span><br><span>The thing is I can't reproduce thi=
 s behaviour. &nbsp;I even ran it on a RELENG_6 system and it worked fine the=
 re.</span><br></blockquote><div><br></div>And it worked fine here until, sus=
 piciously, I lost port 25 service. Coincidence, I'm sure, but that's when I n=
 oticed it.&nbsp;</div><div><br><blockquote type=3D"cite"><blockquote type=3D=
 "cite"><div style=3D"display: none; "><br></div></blockquote><span></span><b=
 r><span>But it's a PR for the mail/postgrey port. &nbsp;It sounds like it's r=
 easonable to close this PR.</span><br></blockquote><div><br></div>I have no i=
 dea what piece of code is balking, I just know what provokes it. Hence the w=
 ording: "<span style=3D"font-family: '.HelveticaNeueUI'; font-size: 15px; li=
 ne-height: 19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 2=
 6, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.2304=
 69); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-=
 text-size-adjust: none; ">mail/postgrey has surfaced a bug in perl's taint c=
 hecking."&nbsp;</span><br><br></div><div>So close it. I was optimistic that f=
 iling a PR might get more than one pair of eyes looking at it, especially as=
  the error wasn't in the port with which they were associated.&nbsp;</div></=
 div></body></html>=
 
 --Apple-Mail-BBBDAB24-12EB-4514-B60A-24C860CE312D--

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Fri, 29 Mar 2013 11:02:17 -0700

 This is actually a little weirder by the day. I don't know how file =
 timestamps would revert to older dates, as I seemed to be finding.=20
 
 This file is called out by postgrey when it bails on the taint error.=20
 ls -l /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm=20
 -r--r--r--  1 root  wheel  13572 May 13  2009 =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm
 
 If I remove the file, it then uses this one:
 
 ls -l /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 -r--r--r--  1 root  wheel  13834 Mar 23 20:43 =
 /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 
 Then I discovered that first file doesn't actually belong to perl-5.14 =
 but to p5-IO-1.25. The second one is installed by perl itself.=20
 
 We have never compared file sizes or hashes on these files.=20
 
 I pulled the list of ports needed to build postgrey:=20
 
 This port requires package(s) "db47-4.7.25.4 p5-BerkeleyDB-0.51 =
 p5-Digest-HMAC-1.03 p5-IO-Multiplex-1.13 p5-IO-Socket-INET6-2.69 =
 p5-Net-DNS-0.72 p5-Net-Server-2.007 p5-Parse-Syslog-1.10 p5-Socket6-0.23 =
 perl-5.14.2_3" to run.
 
 Then I ran deinstall distclean reinstall against each of them. I see =
 that p5-IO isn't on that list, though I assume the p5-IO-* ports depend =
 on it.=20
 
 If this is a b*rked install, it's very subtle.=20
 
 postgrey will run against either of these two files, assuming they =
 exist. It defaults to the older one that had the May 13 2009 timestamp =
 but still bails with the taint error if you choose to run with a port =
 but will run with the socket option. Still can't daemonize.=20
 
 [root@shuttle /usr/ports/devel/p5-IO]# ls -l =
 /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 -r--r--r--  1 root  wheel  13834 Mar 23 20:43 =
 /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 [root@shuttle /usr/ports/devel/p5-IO]# ls -l =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm
 ls: /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm: No such =
 file or directory
 
 The timestamp on the Socket.pm is near identical to that of the perl =
 binary, suggesting that perl installs a Socket.pm of its own as part of =
 the base install. So p5-IO isn't a dependency of postgrey or the p5-IO-* =
 ports as that functionality is part of the base install of perl.=20
 
 I suppose the best approach now is to remove perl and everything that =
 depends on it, then reinstall it from scratch. But I have the strong =
 suspicion I'll end up in the same place, that I'll have multiple =
 IO::Socket files. It sounds like the p5-IO port should be deprecated if =
 it's in the base install.=20
 
 I really can't get my mind around how this happens: how can I remove the =
 file by deinstalling, verify that it's gone, reinstall from a cleaned =
 port directory, and end up with a file with an almost 4 year old =
 timestamp?=20
 
 [root@shuttle /usr/ports/devel/p5-IO]# make deinstall=20
 =3D=3D=3D>  Deinstalling for devel/p5-IO
 =3D=3D=3D>   Deinstalling p5-IO-1.25,1
 [root@shuttle /usr/ports/devel/p5-IO]# ls -l =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm=20
 ls: /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm: No such =
 file or directory
 [root@shuttle /usr/ports/devel/p5-IO]# make reinstall=20
 =3D=3D=3D>  Installing for p5-IO-1.25,1
 =3D=3D=3D>   p5-IO-1.25,1 depends on file: /usr/local/bin/perl5.14.2 - =
 found
 =3D=3D=3D>   Generating temporary packing list
 Files found in blib/arch: installing files in blib/lib into architecture =
 dependent library tree
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/auto/IO/IO.so
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/auto/IO/IO.bs
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Pipe.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/File.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Select.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Poll.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Handle.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Dir.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Seekable.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket/INET.pm
 Installing /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket/UNIX.pm
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Pipe.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::File.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Select.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Socket::INET.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Socket.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Socket::UNIX.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Poll.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Dir.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Handle.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO::Seekable.3
 Installing /usr/local/lib/perl5/5.14.2/man/man3/IO.3
 =3D=3D=3D>   Compressing manual pages for p5-IO-1.25,1
 =3D=3D=3D>   Registering installation for p5-IO-1.25,1
 [root@shuttle /usr/ports/devel/p5-IO]# ls -l =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm=20
 -r--r--r--  1 root  wheel  13572 May 13  2009 =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm
 
 So at this point, I think generating list of installed ports, removing =
 everything, and reinstalling from scratch seems like a good idea. =
 Tedious and likely to require a lot more supervision than I care to =
 provide. I have not found an automated way to do this other than to =
 simple list the ports as a list and build them. portmaster's man page =
 offers some guidance on a process but I never got it to run to =
 completion.=20
 
 Running this [ ls /var/db/pkg/p5* | grep : | sed 's/\(.*\)-/\1\ /' | cut =
 -d" " -f1] to generate a list of ports should work though it didn't last =
 time I tried it, obviously. What would be useful is a check to see if a =
 port is depended on.=20
 
 
 

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Fri, 29 Mar 2013 12:11:45 -0700

 On 2013-03-29 11:02, Paul Beard wrote:
 > I really can't get my mind around how this happens: how can I remove
 > the file by deinstalling, verify that it's gone, reinstall from a
 > cleaned port directory, and end up with a file with an almost 4 year
 > old timestamp?
 
 I'm not sure about the timestamp, but the path to the older Socket.pm 
 doesn't exist on any of my systems.  I hate to sound like a broken 
 record, but I really do think you have a broken perl install.  Now I 
 think you have a broken perl install that won't be fixed without wiping 
 out your entire perl install (perl, p5 modules, and everything that uses 
 perl), deleting distfiles, deleting work dirs, portsnapping a fresh 
 tree, then reinstalling perl and p5 modules *only* by way of 
 dependencies from other ports.

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Fri, 29 Mar 2013 13:38:52 -0700

 On Mar 29, 2013, at 12:11 PM, Darren Pilgrim <ports.maintainer@evilphi.com> w=
 rote:
 
 > Now I think you have a broken perl install that won't be fixed without wip=
 ing out your entire perl install (perl, p5 modules, and everything that uses=
  perl), deleting distfiles, deleting work dirs, portsnapping a fresh tree, t=
 hen reinstalling perl and p5 modules *only* by way of dependencies from othe=
 r ports.
 
 Which is essentially what I started running a couple of hours ago. I removed=
  perl, including all the numbered/versioned paths, everything p5-* in /var/d=
 b/pkg, all distfiles and work directories. I'll reinstall what was there and=
  then try removing ports that are no longer needed. I don't know of a reliab=
 le way to only build needed ports unless there is an incantation to review a=
  list any only install p5-* based ports.=20
 
 My guess is there are a few more installs like this just waiting to hit this=
  bug. It would probably be good to find it with a less destructive process. I=
 nteresting that it had been noted in earlier versions of perl on other platf=
 orms.=20
 
 --
 This space intentionally left blank.=20
 
 

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Fri, 29 Mar 2013 15:22:15 -0700

 On Mar 29, 2013, at 12:11 PM, Darren Pilgrim =
 <ports.maintainer@evilphi.com> wrote:
 
 > Now I think you have a broken perl install that won't be fixed without =
 wiping out your entire perl install (perl, p5 modules, and everything =
 that uses perl), deleting distfiles, deleting work dirs, portsnapping a =
 fresh tree, then reinstalling perl and p5 modules *only* by way of =
 dependencies from other ports.
 
 Which is fine but doesn't answer any of the questions I have had about =
 this.=20
 
 =95	 Where does that older Socket file come into it?=20
 =95	Is p5-IO in the base, i.e., do the files installed by the port =
 replicate functionality that is now included in the base install? The =
 distinfo's modification date is May 17, 2011. The Makefile doesn't test =
 for a version. If so, why does it exist as a port? If it's only for =
 older versions, there's usually a test for that.=20
 =95	Is this just a namespace collision? Or cruft?=20
 =95	Where do the two file files differ? I could mount the cloned =
 copy of the filesystem that has the now-deleted perl tree on it and look =
 into it.=20
 
 
 --
 Paul Beard
 
 Are you trying to win an argument or solve a problem?=20
 

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Fri, 29 Mar 2013 15:36:08 -0700

 On 2013-03-29 15:22, Paul Beard wrote:
 > Is p5-IO in the base, i.e., do the files installed by the port
 > replicate functionality that is now included in the base install? The
 > distinfo's modification date is May 17, 2011. The Makefile doesn't
 > test for a version. If so, why does it exist as a port? If it's only
 > for older versions, there's usually a test for that.
 
 There's plenty of outdated stuff in the ports tree.  Historically a port 
 didn't get deleted until it was unmaintained AND marked broken for a 
 significant length of time.  It's why portscout and its predecessors exist.
 
 > Is this just a namespace collision? Or cruft?
 
 Namespace collisions and multiple-implementation cruft are the 
 characteristics of (what used to be called) CPAN-hell. :)

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Fri, 29 Mar 2013 15:46:37 -0700

 =3D=3D=3D>>> The following actions were performed:
         Installation of devel/p5-IO-Multiplex (p5-IO-Multiplex-1.13)
         Installation of net/p5-Socket6 (p5-Socket6-0.23)
         Installation of net/p5-IO-Socket-INET6 (p5-IO-Socket-INET6-2.69)
         Installation of dns/p5-Net-DNS (p5-Net-DNS-0.72)
         Installation of net/p5-Net-Server (p5-Net-Server-2.007)
         Re-installation of postgrey-1.34_4
 
 [root@shuttle /usr/ports]# postgrey --inet=3D10023 =
 --pidfile=3D/var/run/postgrey.pid --user=3Dpostgrey --group=3Dpostgrey  =
 --dbdir=3D/var/db/postgrey
 2013/03/29-15:36:21 postgrey (type Net::Server::Multiplex) starting! =
 pid(95738)
 Resolved [localhost]:10023 to [::1]:10023, IPv6
 Resolved [localhost]:10023 to [::1]:10023, IPv6
 Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
 Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
 Duplicate configuration (TCP) on [::1]:10023 with IPv6) - skipping
 Duplicate configuration (TCP) on [127.0.0.1]:10023 with IPv4) - skipping
 Binding to TCP port 10023 on host ::1 with IPv6
 Insecure dependency in socket while running with -T switch at =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm line 80.
 
 Now check out the date on that file.=20
 
 ls -l /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm=20
 -r--r--r--  1 root  wheel  13572 May 13  2009 =
 /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm=20
 
 I think I have a ghost at this point. I deleted that entire hierarchy =
 before reinstalling perl from scratch and the ports noted above.=20
 
 pkg_which /usr/local/lib/perl5/site_perl/5.14.2/mach/IO/Socket.pm=20
 [Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 1617 =
 packages found (-41 +0) (...) done]
 p5-IO-1.25,1
 
 [root@shuttle /usr/ports]# ls -l /usr/local/lib/perl5/site_perl/
 total 8
 drwxr-xr-x  152 root  wheel  3584 Mar 29 15:12 5.14.2
 [root@shuttle /usr/ports]# ls -l `which perl`
 lrwxr-xr-x  1 root  wheel  25 Mar 29 11:31 /usr/bin/perl -> =
 /usr/local/bin/perl5.14.2
 
 
 [root@shuttle /usr/ports]# pkg_delete -df /var/db/pkg/p5-IO-1.25,1
 deleted with no dependency warnings, so it was cruft after all.=20
 
 postgrey --inet=3D10023 --pidfile=3D/var/run/postgrey.pid =
 --user=3Dpostgrey --group=3Dpostgrey  --dbdir=3D/var/db/postgrey
 2013/03/29-15:41:44 postgrey (type Net::Server::Multiplex) starting! =
 pid(96283)
 Resolved [localhost]:10023 to [::1]:10023, IPv6
 Resolved [localhost]:10023 to [::1]:10023, IPv6
 Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
 Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4
 Duplicate configuration (TCP) on [::1]:10023 with IPv6) - skipping
 Duplicate configuration (TCP) on [127.0.0.1]:10023 with IPv4) - skipping
 Binding to TCP port 10023 on host ::1 with IPv6
 Insecure dependency in socket while running with -T switch at =
 /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm line 80.
 [root@shuttle /usr/ports]# ls -l =
 /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 -r--r--r--  1 root  wheel  13834 Mar 29 11:28 =
 /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 
 pkg_which /usr/local/lib/perl5/5.14.2/mach/IO/Socket.pm
 [Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 1616 =
 packages found (-1 +0) (...) done]
 perl-5.14.2_3
 
 postgrey still bails on the taint flag and refuses to daemonize if you =
 go with a socket.=20
 
 Are we having fun yet?=20
 
 
 --
 Paul Beard
 
 Are you trying to win an argument or solve a problem?=20
 

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Fri, 29 Mar 2013 18:21:36 -0700

 OK, with just these perl modules installed:=20
 /var/db/pkg/p5-BerkeleyDB-0.51:
 /var/db/pkg/p5-Digest-HMAC-1.03:
 /var/db/pkg/p5-IO-Multiplex-1.13:
 /var/db/pkg/p5-IO-Socket-INET6-2.69:
 /var/db/pkg/p5-IO-stringy-2.110:
 /var/db/pkg/p5-Net-DNS-0.72:
 /var/db/pkg/p5-Net-Server-2.007:
 /var/db/pkg/p5-Parse-Syslog-1.10:
 /var/db/pkg/p5-Socket6-0.23:
 
 postgrey does what it should.=20
 
 But as you might imagine, that's not really very useful. I suppose the =
 best way to unearth the bug is to install all the old ports, one at a =
 time, and check to see if/when postgrey loses its mind again.=20
 
 

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Fri, 29 Mar 2013 19:01:46 -0700

 On 2013-03-29 18:21, Paul Beard wrote:
  > OK, with just these perl modules installed:
  > /var/db/pkg/p5-BerkeleyDB-0.51:
  > /var/db/pkg/p5-Digest-HMAC-1.03:
  > /var/db/pkg/p5-IO-Multiplex-1.13:
  > /var/db/pkg/p5-IO-Socket-INET6-2.69:
  > /var/db/pkg/p5-IO-stringy-2.110:
  > /var/db/pkg/p5-Net-DNS-0.72:
  > /var/db/pkg/p5-Net-Server-2.007:
  > /var/db/pkg/p5-Parse-Syslog-1.10:
  > /var/db/pkg/p5-Socket6-0.23:
  >
  > postgrey does what it should.
 
 I'm glad you got it working!
 
 > But as you might imagine, that's not really very useful. I suppose
 > the best way to unearth the bug is to install all the old ports, one
 > at a time, and check to see if/when postgrey loses its mind again.
 
 Yes, that would be the only way to know for sure which module is the 
 culprit.  It's time-intensive, but it would be worth it to hunt down the 
 stale perl module.  You could install them in dependency groups.  At 
 least that way you can pare it down to a handful for which you must test 
 one by one, instead of all 600.
 

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Fri, 29 Mar 2013 19:25:10 -0700

 On Mar 29, 2013, at 7:01 PM, Darren Pilgrim =
 <ports.maintainer@evilphi.com> wrote:
 
 > Yes, that would be the only way to know for sure which module is the =
 culprit.  It's time-intensive, but it would be worth it to hunt down the =
 stale perl module.  You could install them in dependency groups.  At =
 least that way you can pare it down to a handful for which you must test =
 one by one, instead of all 600.
 
 I have no idea where to start with that. Is there a way to query for =
 what port requires a module? I keep searching but it seems like =
 everything is geared to find what ports you need to install rather than =
 what ports rely on X. The smarter option would have been to check dates =
 in /var/db/pkg and see what was updated when this started. But it looks =
 like every perl module was touched on March 22, with just a few on March =
 23 =97 the ones that postgrey depends on. p5-IO was installed updated on =
 the 22nd. I would like to know what ports depend on that.=20
 
 
 
 --
 Paul Beard
 
 Are you trying to win an argument or solve a problem?=20
 

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Sat, 30 Mar 2013 12:45:15 -0700

 On 2013-03-29 19:25, Paul Beard wrote:
 > Is there a way to query for
 > what port requires a module? I keep searching but it seems like
 > everything is geared to find what ports you need to install rather
 > than what ports rely on X.
 
 `pkg_info -R <port>` or `pkg info -r <port>`
 
 > The smarter option would have been to
 > check dates in /var/db/pkg and see what was updated when this
 > started.
 
 I meant that instead of reinstalling all 600+ p5 modules themselves, 
 just reinstall the ports that use perl/p5 modules and let the dependency 
 system install them for you.  Work flow like this:
 
 1. Get list of installed perl modules;
 2. Reinstall a perl-depending port;
 3. Test postgrey;
 
 If postgrey still works, repeat from step 1.  If postgrey is now broken:
 
 4. Get a new list of installed perl modules;
 5. Compare lists from steps 1 and 4;
 6. Remove ONE of the newly-added modules;
 7. Test postgrey;
 
 If postgrey is still broken, repeat from step 6.  If postgrey now works, 
 you found the culprit module.
 
 If you get all the way through your list of perl-depending ports (not 
 the modules, the top-level ports), then you can conclude you had cruft 
 from a disused perl module.

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Sat, 30 Mar 2013 13:17:11 -0700

 On Mar 30, 2013, at 12:45 PM, Darren Pilgrim =
 <ports.maintainer@evilphi.com> wrote:
 
 > If you get all the way through your list of perl-depending ports (not =
 the modules, the top-level ports), then you can conclude you had cruft =
 from a disused perl module.
 
 Not sure how to follow your plan with modules that aren't installed, at =
 least not without a lot of extra steps. I have a list that has origins =
 as well, so reading through it might not be too problematic. I don't =
 know how to work with uninstalled packages. What I never seem to be able =
 to find is the inversion of a dependency, for lack of a better =
 description: what port requires this one?=20
 
 make pretty-print-build-requires-list is what I think I'm looking for.=20=
 
 
 Seems to me there should be a database, even a text file that one could =
 search, with this information. Rows of port names, columns with version, =
 maintainer, status, run dependencies, build dependencies, and if it was =
 really useful, one could extract all the files that live in a port's =
 directory =97 Makefile, distinfo, pkg-descr, pkg-plist, file in files/ =97=
  from that source, using some wrapper script. Maybe that already =
 exists=85?=20
 
 Right now I have 21(!) p5-* ports installed and everything seems to =
 work. I'm sure some breakage will emerge before too long but to go from =
 600 to 21 with no immediate issues tells the tale. I've removed a few =
 ports that were probably installed as build dependencies. I've run =
 through pkgdb -Fa to sort out dependencies and remove ports that I don't =
 need and with them, their dependencies. What would be interesting would =
 some way to know, short of remembering, when some binary was last used =
 as a way of validating the port's necessity.=20
 --
 Paul Beard
 
 Are you trying to win an argument or solve a problem?=20
 

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Sat, 30 Mar 2013 13:37:11 -0700

 On 2013-03-30 13:17, Paul Beard wrote:
 >
 > On Mar 30, 2013, at 12:45 PM, Darren Pilgrim
 > <ports.maintainer@evilphi.com> wrote:
 >
 >> If you get all the way through your list of perl-depending ports
 >> (not the modules, the top-level ports), then you can conclude you
 >> had cruft from a disused perl module.
 >
 > Not sure how to follow your plan with modules that aren't installed,
 > at least not without a lot of extra steps.
 
 Because you're going at it backwards.  Just reinstall the top-level 
 ports.  Top-level ports are things like postgrey, pflogsumm, 
 fastest_cvsup, etc.  Reinstall those ports and they will reinstall perl 
 and perl modules as dependencies.  You can figure out which ports depend 
 on perl modules by simply listing off dependencies for everything you 
 have installed.

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Sat, 30 Mar 2013 14:26:47 -0700

 On Mar 30, 2013, at 1:37 PM, Darren Pilgrim =
 <ports.maintainer@evilphi.com> wrote:
 
 > Because you're going at it backwards.=20
 
 It only looks that way. If I want to know what port requires this one, I =
 don't want to install other ports on a fishing expedition to find it. =
 Computers are really good at finding things, keeping lists, searching =
 and sorting. It seems like I should be able to search for ports that =
 require a specific one.=20
 
 So what I am looking for is leaf ports (top-level ports makes more sense =
 but isn't used as an option). To me, that's backwards.=20
 
 Anyway: portmaster -l returns this:=20
 
 =3D=3D=3D>>> 293 leaf ports
 
 Hmm, that's a lot. After I winnow them down to the ones I actually use, =
 I could simply run make pretty-print-build-depends-list against each =
 one, sort the results to see what perl modules, if any surface, and test =
 postgrey against them.=20
 
 It's too nice a day to faff about with this but I'll let you know if =
 anything turns up.=20
 
 --
 Paul Beard
 
 Are you trying to win an argument or solve a problem?=20
 

From: Paul Beard <paulbeard@gmail.com>
To: Darren Pilgrim <ports.maintainer@evilphi.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
Date: Wed, 3 Apr 2013 09:05:26 -0700

 So this is resolved, as best I can tell with no inbound smtp to check it =
 with. I never determined what port was the issue.=20
 
 My count of p5 ports is down to 54. Everything seems to work. I did hit =
 an error on a portmaster run where the port had some traces of CVSup =
 which got me a string of warning messages. I haven't used CVSup in quite =
 some time. So there's probably more of that out there waiting to be =
 tripped over.=20
 
 Are there any existing scripts or tools that review installed ports, =
 other than libchk and pkg_check? What I take away from this is that I =
 should be prepared to rip out every perl module and then reinstall all =
 the leaf ports, just to make sure there are no collisions. So in the =
 event perl5.16 becomes the default, I may do that.=20
 
 I never did find out why there is a p5-IO  port installed alongside the =
 same named port in the base perl install. That was part of the issue, =
 that postgrey was using trying to use it based on the name. But I never =
 worked out uninstalling it and rebuilding perl didn't solve it. Or how =
 it kept coming back with 4 year old timestamps.=20
 
 
 
 
 --
 Paul Beard
 
 Are you trying to win an argument or solve a problem?=20
 

From: Darren Pilgrim <ports.maintainer@evilphi.com>
To: Paul Beard <paulbeard@gmail.com>
Cc: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Wed, 03 Apr 2013 12:14:29 -0700

 On 2013-04-03 09:05, Paul Beard wrote:
 > So this is resolved, as best I can tell with no inbound smtp to check
 > it with. I never determined what port was the issue.
 
 I agree it seems like the issue is solved and we can close this PR.
 
 > Are there any existing scripts or tools that review installed ports,
 > other than libchk and pkg_check?
 
 portugprade comes with some extra tools.  I just use portmaster and the 
 basic pkg tools.
 
 > What I take away from this is that I
 > should be prepared to rip out every perl module and then reinstall
 > all the leaf ports, just to make sure there are no collisions. So in
 > the event perl5.16 becomes the default, I may do that.
 
 I don't think that's necessary.  A lot of what you just did was cleaning 
 out stale ports and (hopefully) correcting any package database 
 corruption.  I'd do the normal perl5.n -> perl5.(n+2) upgrade process 
 first and see if it works.
State-Changed-From-To: feedback->closed 
State-Changed-By: stefan 
State-Changed-When: Mon Apr 29 10:27:17 UTC 2013 
State-Changed-Why:  
Submitter and maintainer agree that this can be closed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=177416 

From: Mark Linimon <linimon@lonesome.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint
 checking
Date: Sun, 23 Jun 2013 01:23:35 -0500

 ----- Forwarded message from Paul Beard <paulbeard@gmail.com> -----
 
 Date: Fri, 21 Jun 2013 14:16:48 -0700
 From: Paul Beard <paulbeard@gmail.com>
 To: Philip Paeps <philip@freebsd.org>
 Cc: freebsd-ports-bugs@FreeBSD.org
 Subject: Re: ports/177416: mail/postgrey has surfaced a bug in perl's taint checking
 X-Mailer: Apple Mail (2.1508)
 
 
 On Jun 21, 2013, at 2:13 PM, Philip Paeps <philip@freebsd.org> wrote:
 
 > I only tried with a UNIX socket, not with an INET socket, but the
 > culprit is likely the same: Socket.pm is pulling in some other module
 > that taints what its passing to the socket call.  Unfortunately, I
 > don't seem to have a Perl module on my system causing it to fail anymore
 > (after getting rid of Getopt::Long).
 
 On further testing, I found I can reliably cause it to hang without displaying the Taint error if I use a unix socket but it always works on a port. The presence of the port you found is the toggle. Nice work ;-) 
 --
 Paul Beard
 
 This space intentionally left blank. 
 
 ----- End forwarded message -----
>Unformatted:
