[issue8108] test_ftplib fails with OpenSSL 0.9.8m
report at bugs.python.org
Mon Mar 15 01:11:29 CET 2010
Bill Janssen <bill.janssen at gmail.com> added the comment:
>> Depends on what we want. It just suppresses information that's now
>> available. What we'd really like is for the caller to recognize that
>> close() can fail, and should be re-tried if it does. That requires
>> that we signal the error back up and out of the ssl module. It seems
>> to me that any non-blocking code should recognize this and respect it.
> Well, first, it will break code which used to work perfectly well (as > the failing tests show). That OpenSSL decided to break compatibility
> in what looks like a minor bugfix release (0.9.8m) doesn't mean we
> should propagate the breakage.
I admit to being powerfully swayed by this argument. Of course, you could also say that it exposes bugs in code which hasn't been tested enough. Again, look at where this stack trace is coming from. It's a default error handler in code that was written 10 years ago. Perhaps that code needs more than just a default error handler; perhaps the handler in FTP_TLS should be more sophisticated.
> Second, I'm not an SSL expert, but it's not obvious to me that the
> application should have to ensure a "complete shutdown" before
> closing the socket. Often, stateful applicative protocols close
> their "session" anyway (*) before shutting down the transport layer,
> so I don't see what this additional precaution can buy
> (apart from code complication).
What it buys is the ability for careful code to properly shut down an SSL session when using non-blocking sockets. If we apply the fix, we deny that, and I'm sure someone will immediately file a bug about it :-).
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list