patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)
Martin v. Löwis wrote:
Martin v. Löwis <martin@v.loewis.de> added the comment:
So all Chris has to do to get this applied to 2.5 is craft an exploit based on the current behavior, right? ;-)
Right :-) Of course, security patches should see a much more careful review than regular bug fixes.
Well, it's funny you say that, since where I bumped into this, the bug was effectively DOS'ing a couple of mailservers as a result of mailinglogger sending out log entries of uncaught exceptions such as this and so emitting 100Mb emails whenever the foreign server chose not to deliver the whole chunk requested... That aside, is it actually a python-wide policy to *forbid* patching older releases where the patch isn't security-related? I can understand the "no more releases unless there are security problems", but what's the harm in applying a patch to an old version branch on the off chance that a security release might be made some time? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
That aside, is it actually a python-wide policy to *forbid* patching older releases where the patch isn't security-related?
I can understand the "no more releases unless there are security problems", but what's the harm in applying a patch to an old version branch on the off chance that a security release might be made some time?
Precisely because if we're doing a security release, we want to be sure that that the *only* change that gets included is the fix to the security problem. If there are other changes hanging around on the branch, then the release would need to go at least a single release candidate cycle (which we don't want to need to do for security releases on old branches). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
That aside, is it actually a python-wide policy to *forbid* patching older releases where the patch isn't security-related?
I set this policy for the releases I manage, namely 2.4 and 2.5. I still plan to write a PEP on security releases, and how they relate to maintenance releases.
I can understand the "no more releases unless there are security problems", but what's the harm in applying a patch to an old version branch on the off chance that a security release might be made some time?
Yes. *Every* change causes the risk of breaking something. In fact, for any non-doc change, it is possible to construct a program that breaks under the change. The longer a release is in production use, the less breakage can be risked. People will have worked around all regular bugs that they may have run into. So when they ever make the experience that installing a security fix actually breaks their working code, they will refrain from ever installing Python patches again. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 5, 2009, at 6:18 PM, Martin v. Löwis wrote:
That aside, is it actually a python-wide policy to *forbid* patching older releases where the patch isn't security-related?
I set this policy for the releases I manage, namely 2.4 and 2.5.
This is a Python-wide policy. When Python 2.7 is released, there will be one last 2.6.x bug fix release, and then it will go into security-only mode. Similarly, when Python 3.1 is released, there will be one last 3.0.x release and it too will go into security-only mode. Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSbBgJHEjvBPtnXfVAQIEbQP6Ah9I4SikMQ++vlSYb4BdNgw0VXF/8PMH aTkG0+haOBoJ+mJ9G5GbBiJVtnV0B6qRV1gSV5FSIOzbQE/t0zU27APwnIWv57l9 uZIyyjU1AA0Gz5DSOsC9xtoAqEu/iFH9aRd17tE/N2Yib5p62myqAUVHIRPBl0fD sh+ztoL3q2c= =vgz0 -----END PGP SIGNATURE-----
Barry Warsaw wrote:
That aside, is it actually a python-wide policy to *forbid* patching older releases where the patch isn't security-related?
I set this policy for the releases I manage, namely 2.4 and 2.5.
This is a Python-wide policy.
...and, now that Martin has explained it, it makes perfect sense...
When Python 2.7 is released, there will be one last 2.6.x bug fix release, and then it will go into security-only mode. Similarly, when Python 3.1 is released, there will be one last 3.0.x release and it too will go into security-only mode.
...of course, in a perfect work, it'd be nice to have 2 or 3 previous second point releases in bug-fix mode, rather than just one ;-) Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Martin v. Löwis wrote:
Martin v. Löwis <martin@v.loewis.de> added the comment:
So all Chris has to do to get this applied to 2.5 is craft an exploit based on the current behavior, right? ;-) Right :-) Of course, security patches should see a much more careful review than regular bug fixes.
Well, it's funny you say that, since where I bumped into this, the bug was effectively DOS'ing a couple of mailservers as a result of mailinglogger sending out log entries of uncaught exceptions such as this and so emitting 100Mb emails whenever the foreign server chose not to deliver the whole chunk requested...
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. As for backward compatibility: any application which is depending on getting arbitrarily-long lines in its logfile is already insane, and should be scrapped. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsJOB+gerLs4ltQ4RAva/AKC2Ta0edNMxMLxXQM6+WsB4AKo10QCdFF58 ghfy8pT6VlrO0z0QoXnjL7o= =9lCT -----END PGP SIGNATURE-----
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.
As for backward compatibility: any application which is depending on getting arbitrarily-long lines in its logfile is already insane, and should be scrapped.
That's not the point. The point is that the very old releases don't get sufficient review for bug fixes, because too few people care about them. So a systematic, efficient review by a single person of the entire release must be possible. This is only possible if the number of changes is kept to an absolute minimum - just the patches targeted at the audience of these releases. Regards, Martin
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
Tres Seaver 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.
I just captured the original exception and re-raised it as a subclass with a sane __repr__ cheers, Chris
participants (6)
-
"Martin v. Löwis" -
Barry Warsaw -
Chris Withers -
Nick Coghlan -
rdmurray＠bitdance.com -
Tres Seaver