bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32

[João Távora]

On Sun, May 19, 2013 at 4:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: João Távora <joaotavora@gmail.com>
>> Date: Sun, 19 May 2013 12:45:12 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, 14380@debbugs.gnu.org, emacs-devel@gnu.org
>>
>> The fix I proposed aims for the status quo, that is: make external
>> TLS binary support slightly more robust.
>
> I already said at lest twice in this thread: THIS WON'T WORK on
> Windows (except in Cygwin Emacs).  The communications between the

Look, there's no need to shout. I'm not using Cygwin emacs, I'm using
regular W32
binaries and am not even sure what tls binary emacs found or how. It
appears to be:

"openssl s_client -connect imaps.mycompany.com:993 -no_ssl2 -ign_eof"

My analysis of the code of `network-stream-open-tls' revealed (as do
the comments)
that it tries to cleanup the process buffer of previous garbage left there by
`open-tls-stream` (who nonetheless tries to place point correctly in
the process
buffer)

I'm **guessing** "openssl" is a cygwin binary, I didn't even check that.
I **reported** a bug since I considered unexpected behaviour occurred even with
the cleanest of "emacs -Q" run.
I **suggested** a fix because of two reasons: (1) I tried it and it
worked and has
been working since (2) in the context of the interaction between the
two functions
`network-stream-open-tls' and `open-tls-stream' it seemed reasonable
that the latter
cleans up after itself.

Maybe, in my reduced usage of gnus, I haven't gotten to a situation
where things would
break because of signal handling or whatever. Lucky me.

When things do break, I'll happily unzip dlls, I have nothing against that.

Thanks for all the info, feel free to close the bug if you haven't already
Over and out,
João