[issue8108] test_ftplib fails with OpenSSL 0.9.8m
report at bugs.python.org
Sun Apr 11 19:45:37 CEST 2010
Antoine Pitrou <pitrou at free.fr> added the comment:
To just run the test_ftplib tests, you can use:
$ ./python -m test.regrtest -v -uall test_ftplib
(Other tests involving SSL sockets are test_ssl, test_smtpnet,
test_imaplib and test_poplib)
> 1) Some thing that concern me, the "unwrap()" philosophy looks to be
> used to remove SSL from the Python high-level socket handle, so you
> can go back to plaintext mode. You can ONLY perform an unwrap() AFTER
> an SSL_shutdown()==1 has been observed (you need to wait for the other
> end to do something voluntarily).
When the SSL shutdown fails, an exception is raised, which means the
rest of the unwrapping (at the Python "high-level" socket level) doesn't
Therefore, it is safe to call unwrap() again from user code because the
SSL object is still there.
> Also if it is your intention to properly implement an unwrap() like
> this you should disable IO read-ahead mode before calling shutdown for
> the second time, SSL_set_read_ahead(ssl, 0). This stops OpenSSL from
> eating too many bytes accidentally (probably from the kernel into its
> own buffers), from the inbound IO stream, which may not be SSL
> protocol data, it maybe plain text data (behind the last byte of SSL
> protocol data).
Do you know how to cook a simple test to exercise this?
> 2) Due to the IO waiting it looks also necessary to copy the setup of
> SSL_set_nbio() from the read/write paths so the
> check_socket_and_wait_for_timeout() works in sympathy to the callers
> IO timeout reconfiguration.
Thanks for spotting this.
> 5) Please check I have understand the VARARGS method correctly. I
> have made the default to SSL_SHUTDOWN_MODE_SENT (despite backward
> compatibly being SSL_SHUTDOWN_MODE_ONCE), this is because I would
> guess that most high-level applications did not intend to use it in
> raw mode; nor be bothered with the issues surrounding correct usage.
> I would guess high-level applications wanted Python to take the strain
Yes, sounds right indeed. I'm not sure we need a choice of shutdown
modes at all.
> building works ok, testing fails with SIGSEGV. Is this something to
> do with no having _bsddb built ? I have db-4.3 working. Maybe
> someone can reply by email on the matter.
_bsddb seems to be built, it's the old bsddb185 which isn't.
The module apparently breaks when importing it, can you open a separate
issue for it?
I'd like Bill Janssen's opinion on these proposed changes. Bill, can you
take a look?
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list