This appears to be a concern for some people. Maybe the builtin ssl module should be deprecated if there isn't a lot of manpower to maintain it and instead the well-maintained pyOpenSSL package should become the recommended tool?

Here is a letter that I just received, in my role as a developer of Tahoe-LAFS, from a concerned coder who doesn't know much about Python:

> An FYI on Python.
> 
> I'm not sure how businesses handle this (I've always worked in Windows
> shops), but I imagine some might consider pulling Python until it is
> properly secured. Pulling Python might affect Tahoe, which I would
> like to see do well.

Here is my reply to him:

> Thanks for the note warning me about this issue! I appreciate it.
> 
> The Tahoe-LAFS project doesn't use the builtin "ssl" module that comes
> with the Python Standard Library and instead uses the separate
> pyOpenSSL package (and uses the separate Twisted package for HTTP and
> other networking protocols). Therefore this isn't an issue for
> Tahoe-LAFS. I agree that it is potentially a "marketing" issue in that
> people might mistakenly think that Tahoe-LAFS is vulnerable or might,
> as you suggest, blacklist Python as such and thus hit Tahoe-LAFS as
> collateral damage. There's not much I can do about that from the
> perspective of a Tahoe-LAFS developer. From the perspective of 
> contributor to Python, I'm also not sure what to do, except perhaps to
> complain. :-) I guess I'll try to stir the waters a bit by suggesting
> that Python should deprecate the builtin "ssl" module and recommend
> the pyOpenSSL package instead.