Antoine Pitrou <pit...@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 occur. 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 > here. 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 <rep...@bugs.python.org> <http://bugs.python.org/issue8108> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
