[macports-ports] branch master updated: nrpe, nsca: remove outdated ports
macportsusers-20171215 at billmail.scconsult.com
Mon Feb 4 04:10:32 UTC 2019
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 at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
More information about the macports-users