This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Ben.Darnell
Recipients Ben.Darnell
Date 2015-03-05.04:10:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
In-reply-to
Content
ssl.SSLError is a subclass of OSError but uses error codes that come from a different scope than the standard errno constants and may have conflicts. For example, on my system (OSX), ssl.SSL_ERROR_WANT_X509_LOOKUP and errno.EINTR have the same value. This would cause problems for code like the following:

  def f():
    while True:
      try:
        return ssl_sock.read()
      except OSError as e:
        if e.errno == errno.EINTR:
          continue
        raise

This function would loop endlessly on ssl.SSL_ERROR_WANT_X509_LOOKUP. (Note that I have not run into any problem like this in practice so this is not a severe issue; I just stumbled across the possibility). The EINTR case is moot now that Python itself retries on EINTR, but other conflicts are possible (the problem is also mitigated by the fact that most of the interesting errnos now have dedicated exception subtypes)

To use OSError.errno correctly, it is currently necessary to check the exact type of the exception; it is not enough to do subclass matching as is usual for exceptions. To remedy this, I propose either changing the numeric constants in the SSL module (if these are not required to match constants defined in openssl), or adding an attribute to OSError like 'errno_scope' to be used when interpreting the errno field.
History
Date User Action Args
2015-03-05 04:10:08Ben.Darnellsetrecipients: + Ben.Darnell
2015-03-05 04:10:08Ben.Darnellsetmessageid: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
2015-03-05 04:10:08Ben.Darnelllinkissue23588 messages
2015-03-05 04:10:08Ben.Darnellcreate