reverting recent SSL-related patches

[Eygene Ryabinkin]

Mon, Jan 12, 2015 at 04:56:19PM +0100, Nicolas Sebrecht wrote:
> On Mon, Jan 12, 2015 at 06:24:08PM +0300, Eygene Ryabinkin wrote:
> > However, I had tried to build the model for the class of users that
> > will be fooled by this behaviour (taking for granted that they don't
> > read the documentation).  Basically, cert_fingerprint is a
> > quick'n'dirty way to solve the problem of CA roots and the only
> > affected users are those who are using this option.  Moreover, to be
> > fooled about default behaviour they should know what is default CA
> > bundle, because the only broken expectation is that the bundle will be
> > still used to verify connection even when cert_fingerprint is used.
> > And these users will have no sslcacertfile set, so either
> > 
> >  - they had never tried to use real CA roots (and found out that
> >    default CA bundle errors out for them) and found relief in
> >    cert_fingerprint;
> > 
> >  - they come from pre-default bundle times, so they are fine with
> >    the fact that their server's certificate won't be verified;
> > 
> >  - they are fine with default bundle, but believe that cert_fingerprint
> >    will add extra protection layer.
> > 
> > Only the latter ones seem to be really fooled by OI behaviour I am
> > trying to introduce, expectation of other aren't harmed.  It is likely
> > that they will read the documentation, but I am still not relying
> > on this.
> 
> I disagree a bit. My approach is just to NOT introduce regressions
> without making any assumptions of what the users did or not. The first
> regression comes from the OS-default-CA series.
> 
> The second point is about not confusing the users with a complex CA Cert
> sub-system that sometimes take defaults or not.
> 
> Since your fixed the regression and that I expect the documentation
> avoid confusions enough, I think it is good enough to be merged.

Fine, thanks!  I'll rework a technical side of the code a bit in the
part of fingerprinting our peer to avoid exploiting internals of
imaplib2 too much, test it once again and push if no issues will be
uncovered.

Stay tuned ;))
-- 
rea