emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs core TLS support


From: Nikos Mavrogiannopoulos
Subject: Re: Emacs core TLS support
Date: Wed, 15 Sep 2010 14:13:57 +0200

2010/9/15 Ted Zlatanov <address@hidden>:

> NM> I cannot look at the patch but the example you are looking for is:
> NM> 
> http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support
> NM> to do the connection, and this one to verify the certificate:
> NM> 
> http://www.gnu.org/software/gnutls/manual/html_node/Verifying-peer_0027s-certificate.html#Verifying-peer_0027s-certificate
> Thanks for your help.  I am still a little lost though :)
>
> Can you give a specific command line that would start gnutls-serv so the
> simple client (ex-client2.c) you reference will connect to it?  If
> that's not possible, is there a way to augment ex-client2.c so it
> connects to an invocation of gnutls-serv without building all the
> gnutls-cli (cli.c, etc.) infrastructure?

Use/check the gnutls-http-serv script in doc/credentials. It sets up a
server with a certificate, ready for testing. If the server doesn't
have a certificate it wouldn't be able to fully operate.

> NM> GNUTLS_E_AGAIN is returned only if the transport layer function
> NM> (recv/send) return -1 and EAGAIN. Usually this is normal behavior and is
> NM> enough to loop around them. Do you use non-blocking IO?
> Ah, thanks for the hint.  All the GnuTLS source code (e.g. the
> do_handshake() function in cli.c) keeps looping forever as long as
> GNUTLS_E_AGAIN is returned.  That seems dangerous regardless of the
> underlying mechanism because we don't want to lock up Emacs waiting for
> a connection, but OTOH there's no other way to know if the handshake is
> done.  I limited it to 25000 times (used to be 25) in my patch.  Is that
> a reasonable limit?  Should I base it on time elapsed?
> With a limit of 25K and by checking `gnutls-error-fatalp' which calls
> `gnutls_error_is_fatal', the handshake succeeds after 1250 tries against
> a remote SSL server.  So now against that server I get:

Maybe a time limit would be more reasonable, but it depends on the
context. Why would you use non-blocking IO in that case?

regards,
Nikos



reply via email to

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