emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs and TLS support


From: Ted Zlatanov
Subject: Re: Emacs and TLS support
Date: Sun, 26 Sep 2010 16:33:04 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Sun, 26 Sep 2010 23:06:46 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Ted Zlatanov <address@hidden> writes:
>> I stepped through the GnuTLS function calls and couldn't find a problem
>> with the credential structures.  It's frustrating that the exact same
>> code works for the example client in GnuTLS but breaks in Emacs (most of
>> my time debugging this was spent double-checking that the same functions
>> are called with the same parameters in both cases).

LMI> I know nothing about tls, but have you confirmed that the library calls
LMI> really work in non-blocking mode?  It's not uncommon to write libraries
LMI> that assume that socket connections are blocking...

It would be great if the GnuTLS developers could comment.  But these
references seem to specifically confirm that non-blocking sockets should
work the way I'm doing it:

http://lists.gnupg.org/pipermail/gnutls-dev/2005-March/000839.html
http://www.gnu.org/software/gnutls/manual/html_node/The-transport-layer.html

I tried setting the low water value to 0 in `Fgnutls_handshake' after
`gnutls_transport_set_ptr2' but it didn't make a difference:

    gnutls_transport_set_lowat (state, 0);

So I removed it in the patch.  I sort of suspect right now that
recv/send are not working correctly so I need to provide custom versions
with `gnutls_transport_set_pull_function' and
`gnutls_transport_set_push_function'.  But I don't know enough about the
Emacs internals that set up processes, which are ridiculously
complicated because of all the supported platforms.  And Simon Josefsson
said his patch worked when he first wrote it, so I assumed that this
kind of deep surgery would not be required.

Ted




reply via email to

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