Typedefs sha256_pin_t & getdns_log_config multiple declaration in context.h,
tls.h and tls_internal.h causes build error with some gnu99 compilers, even
if the redefinition is identical.
One possible way is to protect each occurence with ifdefs, but it seems too
brute, other one is to keep typedef in context.h only and use struct types
in recently added tls* scope.
Error example:
../libtool --quiet --tag=CC --mode=compile arm-brcm-linux-uclibcgnueabi-gcc
-std=gnu99 -I. -I. -I./util/auxiliary -I./tls -I./openssl -I./../stubby/src
-Wall -Wextra -D_BSD_SOURCE -D_DEFAULT_SOURCE ... -c ./convert.c -o convert.lo
In file included from ./context.h:53:0,
from ./util-internal.h:42,
from ./convert.c:50:
./tls.h:45:27: error: redefinition of typedef 'sha256_pin_t'
./openssl/tls-internal.h:57:27: note: previous declaration of 'sha256_pin_t' was here
In file included from ./util-internal.h:42:0,
from ./convert.c:50:
./context.h:133:3: error: redefinition of typedef 'sha256_pin_t'
./tls.h:45:27: note: previous declaration of 'sha256_pin_t' was here
./context.h:267:3: error: redefinition of typedef 'getdns_log_config'
./openssl/tls-internal.h:58:34: note: previous declaration of 'getdns_log_config' was here
I found gnutls_certificate_set_x509_trust_(file|dir)(), so it's a lot
easier than I feared. Plus a little diggiing shows that if you're
loading the system defaults, GnuTLS on Windows does load them from the
Windows certificate store.
The previous default cipher string wouldn't connect with getdnsapi.
Selection of cipher strings requires some deep study, I think.
So, taking working with getdnsapi.net as our target, discover that we
need SECURE128 as well as SECURE192. And rather than disable everything
except TLS1.2, disable TLS1.0 and TLS1.1. This should mean it connects
to TLS1.3.
Set the priority string to a concatenation of the connection cipher and curve strings, falling back to the context ones if the connection value isn't specified. Also get context.c to specify NULL for default context list and the opportunistic list for the connection, moving these library-specific quantities into the specific implementation.
Add a flag to the context (so, it's actually got something useful there!) and check the connection version on a successful handshake.
This means we need to access the context from a connection, so add a pointer to the context to the connection.
Link to the openssl val_secalgo implementation and use that, after adjusting the source of Nettle includes.
GnuTLS uses Nettle itself, so this is not adding a new dependency.
Vladislav Grishenko
Willem Toorop
Jim Hague
Jim Hague