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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
