ports/177416: mail/postgrey has surfaced a bug in perl's taint checking

[Paul Beard]

The following reply was made to PR ports/177416; it has been noted by GNATS.

From: Paul Beard <paulbeard at gmail.com>
To: Darren Pilgrim <ports.maintainer at evilphi.com>
Cc: "bug-followup at FreeBSD.org" <bug-followup at 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 at 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=