bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7789: cannot send smtpmail using gmail & tls on woe32


From: Claudio Bley
Subject: bug#7789: cannot send smtpmail using gmail & tls on woe32
Date: Fri, 21 Jan 2011 15:32:33 +0100
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 Emacs/23.2 (i386-mingw-nt5.1.2600) MULE/6.0 (HANACHIRUSATO)

At Tue, 18 Jan 2011 17:45:42 -0500,
Eli Zaretskii wrote:
> 
> > From: address@hidden (Claudio Bley)
> > Date: Tue, 18 Jan 2011 16:33:41 +0100
> > Cc: 
> > 
> > > > gnutls-cli waits for a SIGALRM to initiate the STARTTLS handshake --
> > > > which Emacs isn't able to send -- or, alternatively, an EOF -- which
> > > > doesn't work because communication is done over a pipe instead of a
> > > > PTY.
> > > 
> > > Is this a bug in the ported gnutls, in Emacs, or in both?
> > 
> > I'd say it's a deficiency of the platform.
> 
> A port that doesn't take platform deficiencies into consideration is a
> broken port.  I was asking where should the correction be: in gnutls
> or in Emacs, or in both?

Well, incorporate GNU TLS into Emacs and you're done. Any OS needs
cryptographic and security features nowadays, no?

> > Woe32 has no signal and no PTY support. So, the signal support
> > has been ifdef'ed out in gnutls and Emacs for Woe32.
> 
> If it has been ifdefed out, how are users supposed to do on Windows
> what they do on GNU/Linux by using signals?

Since you only need to signal gnutls-cli once that it should negotiate
the TLS connection, it would be sufficient to set a boolean flag of
some sort. One may use an event e.g. called "gnutls-cli-<PID>" and
provide an auxiliary program which is able to signal events by a given
name.

You could also use a socket. Since Emacs is already able to use
sockets that would only require a change in GNU TLS.

> > > > I'm using cygwin's gnutls-cli and have hacked ssl.el in order to
> > > > replace the signal-process calls with (call-process "kill.exe" nil nil
> > > > nil "-ALRM" PID). This works because cygwin provides its own layer of
> > > > signal handling and is able to send / receive the SIGALRM signal.
> > > 
> > > How about making that hack part of Emacs?  It could be conditioned on
> > > running on Windows.
> > 
> > You mean to distribute cygwin's kill.exe with Emacs and just using it
> > instead of `signal-process' everywhere? Or to depend upon the user to
> > install a cygwin environment along with Emacs?
> 
> The latter, and also that hack in ssl.el you need for that.

Sorry, I actually meant to say that I hacked starttls.el for that
matter.

> Is there a better way that's practical?  It is more awkward to ask
> users to change platforms, or tell them to fix gnutls by themselves,
> no?
> 
> > IMHO, it would be better to let the programs work together on all
> > platforms using different means of notification where necessary,
> > e.g. using events on windows instead of signals...?! But that would
> > indeed require an appropriate change on both sides.
> 
> Exactly.  I'm trying to establish whether there's a less painful way,
> even if it's less elegant.

I just discovered that gnutls-cli is barely usable compiled on native
Woe32 because it uses (must use) polling of stdin, stdout file
descriptors which means 100% CPU usage when idle and connected to a
pipe instead of a real console. Oh my...

So, it seems that the least painful way is to use Cygwin's gnutls-cli
and its kill command. It's still painful, though. And it's actually a
bit slow compared to running it under Linux -- maybe that's because of
the extra layer(s) of Cygwin...







reply via email to

[Prev in Thread] Current Thread [Next in Thread]