Selecting cipher suites with socket.ssl

[Laura Creighton]

Sent twice, apologies to Martin.  Some fool program is mangling things
so that Replied python-list at python.org lines come out python-list at python.
So that didn't work.  Now to find that bug.  Sorry that I did not
notice it until I sent this.

Laura
---------
> Laura Creighton <lac at strakt.com> writes:
> 
> > Why should the OP do this rather than just get our PyOpenSSL, or m2crypto
> > (which also didn't work a year ago when we tried it, either, but I believe
> > does now)?  Why not put our PyOpenSSL (or m2crypto) into Python?  This is
> > a serious question which nobody has answered for nearly a year now.
> 
> I think there are three reasons:
> - none of the authors has offered to contribute them;
> - none of the users have requested an inclusion of a specific such
>   package into Python
> - it is not clear which of these are "good" enough for the standard
>   Python library.
> 
> The third item is particularly important, IMO - apparently, the
> previous attempt at offering SSL support is considered as failed by
> those that need advanced features; those that don't need advanced
> features (like myself) are happy users of the Python SSL support.
> 
> It is IMO pointless to add another package that then will be
> considered as a failure after some time. This stuff is difficult, so
> people need to sit down and identify the requirements, and propose an
> API.
> 
> Outright exposure of the OpenSSL API is IMO the wrong thing to do:
> parts of that are historic, and parts of it are better done in
> different ways in Python than they are in C. What I like about the
> current SSL support in Python is that simple things are easy to do; I
> fear that those packages aiming at exposing OpenSSL fully don't allow
> to do easy things easily.
> 
> Regards,
> Martin

We appear to have a simple misunderstanding. 
1. We offered to contribute them.  it was refused I think due to 2.
2. You are absolutely correct about that, there appears to be almost
   no interest in them, or in certificate generation whatsoever.  About
   every 3 months one more person is found who wants one, which is a
   tiny user community.
3. Well, the only way you can find that out is to read the code.
   I cheerfully admit, given 2, there is probably a better use for your time.

But I don't like the assumption that the OP can do certificate generation
better than Martin Sjögren did.  Maybe you are already familiar with
the OP, (or hate our code, and are being too polite to tell us, even
privately.)  Meetings for common API, though proposed, have come to
naught, basically due to lack of interest.  Those of us who have working
things wrote them for ourselves, so naturally we like them, but as
for 'giving back to the community ...' as far as we can 10 of the 27
people in the whole world who want certificates already work here ...
(I made up the 27; I have no numbers, but it is very small.)

So naturally, there is no big push here to get pyOpenSSL in the standard
library.  But I don't think that the OP should waste his time hacking
on the standard SSL module; pick something that other people want to see.
Besides, whatever he comes up with may be rejected on the grounds that the 
code isn't good enough, or it adds the sort of complexity you don't want in
the standard library.  Modifying an existing library shouldn't be
by definition easier to do than adding a new one -- foul code is foul code