Re: State of procmail
Erich Veyhl <[email protected]> Tue, 09 Aug 2016 18:46:54 -0400
| Newsgroups | gmane.mail.procmail |
|---|---|
| Message-ID | <[email protected]> |
>Date: Mon, 8 Aug 2016 20:12:00 +1000 >From: Erik Christiansen <[email protected]> > >On 07.08.16 10:59, Erich Veyhl wrote: > > First and foremost are unfixed security flaws. Mitre.org lists two > > vulnerabilities affecting procmail since 2001:... That isn't what I wrote. I linked to the article and quoted from it = as of interest. I didn't write the article. >https://www.cvedetails.com/vulnerability-list/vendor_id-225/Procmail.html > >That only ascribes one vulnerability to the current version of procmail. It's described as: "<https://www.cvedetails.com/cve/CVE-2014-3618/>CVE-2014-3618 = <https://www.cvedetails.com/cwe-details/119/cwe.html>119 DoS Exec = Code Overflow 2014-09-08 2015-10-09 score 7.5 Heap-based buffer = overflow in formisc.c in formail in procmail 3.22 allows remote = attackers to cause a denial of service (crash) and possibly execute = arbitrary code via a crafted email header, related to 'unbalanced quotes.'" Is that not a concern? > > In addition, of course, there are other bugs that remain > > unfixed. Matthew G. Saroff pointed out one long-standing bug, and the > > procmail site itself lists a dozen or so known bugs as of 2001. > >There is a list of bugs in the KNOWN_BUGS bug file in the source code. >I don't think we're compelled to fix them until we get around to it, >this century or next. (If not fixed, then they're clearly not hurting >much.) Not being compelled to fix them until getting around to it and not = hurting much meanwhile doesn't address or fix the known bugs. Do = they matter or not? Can they cause problems in procmail operation we = might not realize? Who is the "we"? Is there someone out there who can and still wants = to fix bugs and distribute a new version? > > "Just as importantly, the email landscape and the system > > administration marketplace have not stood still since 2001, either. Ed > > Blackman noted that procmail cannot correctly handle MIME headers > > adhering to RFC 2047 (which include non-ASCII text), despite the fact > > that RFC 2047 dates back to 1996. RFC 2047-formatted headers are far > > from mandatory, but they do continue to rise in frequency." > >Ah, Ed sounds like an academic or writer for a magazine. If that concern >became non-academic for the user community, then we might take a look at i= t. Most of don't care if the "Ed" is academic or a magazine writer. Are = incompatible MIME headers in fact rising in frequency? What is the = affect on how procmail operates and how would we notice it? >In the interim, I'll agree that the email landscape landscape has >not stood still - but reserve judgement on whether it has moved >forwards. Whether it moves forwards, backwards or sideways, or wanders onto = another Riemann sheet or parallel universe, if incompatibilities = arise there will be problems in our own favored procmail environment = here in this world. Is that happening?