Tweak libcheck/windows logic.
Hacks to make tests pass with strange bionic system resolver behaviour
Add to README that xenial doesn’t have libunbound-dev 1.5.9 packaged
sys/poll.h seems to be some GNU extension. musl warns about this:
warning redirecting incorrect #include <sys/poll.h> to <poll.h>
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Add an include of stdlib.h to various files that were relying on config.h to drag it in. I don't think config.h should be pulling in standard C headers.
The change mostly consists of removing or replacing non-standard (usually POSIX) header includes.
Guards for replacements for inet_ntop(), inet_pton() and gettimeofday() are updated; the first two are macros on Windows, so the guards are changed to HAVE_DECL. gettimeofday() is present on MinGW builds but not Visual Studio, so that has a function check.
uClibc 0.9.30rc1 - 0.9.32rc5 has bug - getaddrinfo() does not accept numeric
service without any hints. As the related side effect, hint struct with
ai_socktype == 0 (unspec) and ai_protocol == 0 (unpsec) gives the same
EAI_SERVICE error instead of same address with different proto enumebration.
For more details please refer https://bugs.busybox.net/show_bug.cgi?id=3841 and
https://git.uclibc.org/uClibc/commit/?id=bc3be18145e4d57e7268506f123c0f0f373a15e2
Since 0.9.3x uClibc versions are still not somewhat unique in embedded (issue
https://github.com/getdnsapi/stubby/issues/124 as example) and non-zero
ai_socktype allows to avoid address dups for each supported UDP/TCP/etc proto,
seems worth to have it specified, as a minor memory allocation optimization at
least.
SOCK_DGRAM vs SOCK_STREAM choice doesn't really matter here, both are actually
used for DNS and both are non-zero, no difference is expected on *nix. So
SOCK_DGRAM selected due original comment only.
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
When calculating HTTP request buffer size tas_connect() unnecessarily adds
an extra octet for the terminating NULL byte.
The terminating NULL was already accounted for by sizeof(fmt), however,
since sizeof("123") = 4.
The extra NULL byte at the end of the anchor fetch HTTP request resulted
in an extra "501 Not implemented" HTTP response from the trust anchor
server.
tas_doc_read() uses a very short 50 msec network read timeout which makes
fetching trust anchors pretty much impossible on high-latency connections
like 3G.
Use a 2 second read timeout, just like the other tas_read_cb() callback
setter does.
The isxxxx() and toxxxx() functions have a limited well-defined
input value range, namely that of "unsigned char" plus EOF. Cast
args accordingly.
Bring strncasecmp() into scope by including <strings.h>.
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.
Willem Toorop
Sara Dickinson
Rosen Penev
Jim Hague
Vladislav Grishenko
Maciej S. Szmigiero
Havard Eidnes
Bruno Pagani
Jim Hague