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

Previous Next

Packages: gnus, emacs;

Reported by: joaotavora <at> gmail.com (João Távora)

Date: Fri, 10 May 2013 12:50:02 UTC

Severity: normal

Found in version 24.3

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #41 received at 14380 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14380 <at> debbugs.gnu.org, tzz <at> lifelogs.com
Subject: Re: bug#14380: 24.3; `network-stream-open-tls' fails in some imap
	servers on w32
Date: Sun, 19 May 2013 18:57:43 +0100
On Sun, May 19, 2013 at 4:44 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: João Távora <joaotavora <at> gmail.com>
>> Date: Sun, 19 May 2013 12:45:12 +0100
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 14380 <at> debbugs.gnu.org, emacs-devel <at> 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




This bug report was last modified 11 years and 340 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.