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

[Bill Cole]

On 2 Feb 2019, at 20:59, Dave Horsfall wrote:

> On Sun, 3 Feb 2019, Joshua Root wrote:
>
>> No official policy. My view is that the only clear-cut case is when a 
>> port doesn't build or work at all, anywhere, and there's no real 
>> chance of that ever changing.
>
> How about insecure ports such as Procmail?  It's a scripting language, 
> with Shell access, that believes user data;  I believe it's no longer 
> maintained by the author, and the coding style is unreadable, making 
> it difficult to spot vulnerabilities.
>
> 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.

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.

> 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.

--
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole