[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32
Sun, 19 May 2013 18:57:43 +0100
On Sun, May 19, 2013 at 4:44 PM, Eli Zaretskii <address@hidden> wrote:
>> From: João Távora <address@hidden>
>> Date: Sun, 19 May 2013 12:45:12 +0100
>> Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden
>> 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
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
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
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
`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,
bug#14380: 24.3; `network-stream-open-tls' fails in some imap servers on w32, Eli Zaretskii, 2013/05/19