[macports-ports] branch master updated: nrpe, nsca: remove outdated ports

[Dave Horsfall]

On Sun, 3 Feb 2019, Bill Cole wrote:

>> http://www.cvedetails.com/vendor/225/Procmail.html makes interesting 
>> reading, as does any search for "procmail CVE".  Perhaps it's just me, 
>> but I don't think insecure software belongs in MacPorts unless someone 
>> is willing to fix it (and good luck with Procmail).
>
> The problem with applying that principle to MacPorts is that MacPorts 
> itself has active support for versions of MacOS which have severe, 
> well-documented, and publicly exploited security problems. For examp-le, 
> if you leave a MacOS <10.9 machine open to the net with its stock Apache 
> serving up user 'Sites' directories with the a stock bash as /bin/sh, 
> you'd be lucky to not have it running at least one mining, spamming, or 
> DDoS bot within a week. There are vulnerable elements (such as /bin/sh 
> and of course the kernel) which MacPorts can't address, so it is de 
> facto enabling risky behavior.

Is there no mechanism for "freezing" ports known to be insecure?  Call it 
my FreeBSD background again, but it will yell at you (and after that, it's 
your problem, along with that of the spammees in turn).

> No one who has looked at it seriously can disagree with the fact that 
> procmail is insecure by design and its code is shambolic. Even its 
> author acknowledged that, many years ago, which is why there is no real 
> definitive ultimate upstream site for the code. No one should be 
> starting a new .procmailrc ever again. However, it is possible (by 
> avoiding its riskier features,) to use procmail safely.

Yes, I've heard this elsewhere, but Procmail Must Go Until Fixed [tm].

>> There are alternatives; I cannot remember their names. but "sieve" (or
>> similar) springs to mind.
>
> Yes, "sieve" is a standardized (RFC5228) language for mail filtering 
> during final delivery. There are many implementations, mostly tied to 
> either a specific MTA (e.g. Exim) or mailstore access server (e.g. 
> Dovecot, Cyrus.) Its adoption and use has been hampered by the fact that 
> there's never been a generally recognized independent reference 
> implementation that you can use with a simple entry in a .forward file.

Yeah, that's a pity.  Now, if only the MacPorts Mandarins can pay 
attention...

Perhaps it's just me, but I can spot a buffer overflow a mile away; I 
would hate to run Procmail past malloc() debug, or even worse, Electric 
Fence :-(

Many people (including me) have offered to help, and have been studiously 
ignored in turn; perhaps it's because we are not 100% Mac?

The only thing that can be done to Procmail (apart from a lethal 
injection) is to run it through a pretty-printer[*] or something, so at 
least it's readable.

[*]
But then we'd get bike-shed wars about which format to use :-)

-- Dave