On Mon, 13 Sep 2010 09:49:30 +0200 Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote: 

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?

I can do a test connection with gnutls-cli but that's a much more
complicated program and I'm trying to get the simple connection working,
even without verification.  If I can get the bare minimum SSL and TLS
working I can drop the patch into Emacs and get more eyes on it.  I'm
tempted to do so now so I can stop sending this patch out :)

It would be wonderful, incidentally, if there was a way to configure all
the file options with a single string, similar to the priority string,
and just get back a session.  A config file would also work if a single
string is too hard to parse.  I don't see any options that couldn't work
like this and it would make setting up a GnuTLS connection much easier.

On Tue, 14 Sep 2010 20:55:51 +0200 Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote: 

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:

-24 (Decryption has failed.)

and against "gnutls-serv --priority NORMAL --http" I get

-12 (A TLS fatal alert has been received.)

(the server side says "Error in handshake
Error: Could not negotiate a supported cipher suite.")

which is a lot better: at least the handshake is no longer the problem
and it tells us the transport FDs are set correctly.  So we can progress
to figuring out the bare minimum I mentioned above.

Latest patch attached, as usual.

Thanks again...
Ted