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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
