[Python-Dev] patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)

[rdmurray at bitdance.com]

On Fri, 6 Mar 2009 at 20:57, "Martin v. Löwis" wrote:
>> If it is possible for a hostile outsider to trigger the DOS by sending
>> mail to be processed by an application using the library, and the
>> application can't avoid the DOS without ditching / forking /
>> monkeypatching the library, then I would call the bug a "security bug",
>> period.
>
> IIUC, it would have been straight forward for the mail servers to avoid
> the DOS: simply truncate log lines to 1024 bytes, or something.

I believe that in general things that allow DOS attacks to be staged are
considered security vulnerabilities by the general security community,
albeit of lower priority than exploits.  I believe the logic is that
one would prefer the system administrator not to have to figure out what
caused the DOS and how fix it after getting hit by it and having had a
service outage as a result.

Normally the "vendor" of package with the DOS vulnerability would provide
a fix and push it out, and a conscientious sysadmin would install the
"security release" and thus be protected.  In this case the application
vendor can only fix the DOS bug by modifying the library, and that would
fix it only for that application.  The logical place to fix it is at
the source: the library in question.

But since a DOS is lower priority from a security standpoint, I can
see the argument for not burdening the release maintainer with anti-DOS
patches.

We probably should leave it to the release maintainer to decide based
on some assessment of the likely impact of not fixing it.  Which means
it might not get fixed, but that's the reality of limited development
and maintenance resources.

--RDM