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?