On Jan 10, 2011, at 1:43 PM, Daniel Stenberg wrote: > On Mon, 10 Jan 2011, Quinn Slack wrote: > >> In the code itself, there aren't yet any #ifdefs for TLS-SRP support; if >> GnuTLS is used, then TLS-SRP support will be enabled. There's also no check >> to ensure that the GnuTLS version is new enough (>=2.3) to have the right >> values for the TLS-SRP cipher suite. I'll work on those now. How does >> everything else look, though? > > I did two minor improvements, see patches attached.
Thanks. My patch includes these. > I also found out that using gnutls-serv for this purpose is troublesome: my > gnutls-serv version (2.8.6 on Debian) returns different HTTP contents for me > with the exact same use, compared to what you got and did the test cases for! Your 0002-runtests-check-for-find_gnutls_serv.patch added the -q flag to gnutls-serv, which suppresses a lot of debug info on the HTML page that it serves. I've removed the -q flag in this patch. Does it work for you now? If not, can you send over the diff that runtests.pl prints out? This patch also adds ./configure flags --enable-tls-srp and --disable-tls-srp and checking for GnuTLS with SRP support. If --disable-tls-srp is not specified and GnuTLS supports SRP, then USE_TLS_SRP is #define'd. The TLS-SRP specific code is surrounded with #ifdef USE_TLS_SRP. Since TLS-SRP is the only TLS authentication method currently supported, I surrounded all of the new TLS auth code (like handling the --tlsauthtype SRP flag and urldata.h TLS username/passwd struct fields) with these #ifdefs, not just the TLS-SRP-specific stuff. If another TLS auth type is later supported, this will have to be more general, but it seemed easier to do it like this for now. Is this OK? Passes tests 300-324 with and without USE_TLS_SRP.
0003-curl-tls-srp-with-conditional-compilation.patch
Description: Binary data
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
