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?