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 christian.heimes
Recipients alex, christian.heimes, dstufft, janssen, pitrou
Date 2018-02-25.17:20:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1519579231.24.0.467229070634.issue32951@psf.upfronthosting.co.za>
In-reply-to
Content
Antoine Pitrou replied:

The ssl.SSLSocket constructor was never meant to be called by user
code directly (and I don't think we document it as such).  Anyone doing
this is asking for trouble (including compatibility breakage as we
change the constructor signature).

ssl.wrap_socket() is essentially a legacy API.

I would suggest the following measures :

- Deprecate ssl.wrap_socket() and slate it to be removed around 3.8 or
3.9.  SSLContext is now is any recent 2.7 or 3.x version, so the
compatibility argument doesn't hold anymore.

- Severely de-emphasize ssl.wrap_socket() in the documentation (relegate
it in a "legacy API" section at the end), and put a warning that it's
insecure.


---
Alex Gaynor replied:

If SSLSocket.__init__ is meant to be private and not called by users,
perhaps we could clean up the API and remove all the legacy arguments it
takes, bring it down to just taking a context?

It'd break anyone who was relying on it, but they weren't supposed to be
relying on it in the first place... (Is it documented even?)

---

I have implemented Antoine's second proposal in #28124.
History
Date User Action Args
2018-02-25 17:20:31christian.heimessetrecipients: + christian.heimes, janssen, pitrou, alex, dstufft
2018-02-25 17:20:31christian.heimessetmessageid: <1519579231.24.0.467229070634.issue32951@psf.upfronthosting.co.za>
2018-02-25 17:20:31christian.heimeslinkissue32951 messages
2018-02-25 17:20:31christian.heimescreate