Sorry for not using "github" to report a problem but I don't have
an account there...
Anyway, it seems the order of the libraries ssl and crypto is wrong:
with -lcrypto -lssl configure fails to find ub_fd():
: undefined reference to `SRP_Calc_A'
changing it to
-lssl -lcrypto
resolves the problem (and matches the order elsewhere,
e.g., unbound).
i noticed that libgetdns.so is being linked against libdl, but i don't
think we're using dlopen or any of the other functions exported from
ldl.
fwict, ./configure is adding -ldl because of m4/acx_openssl.m4, which
claims:
# openssl engine functionality needs dlopen().
BAKLIBS="$LIBS"
AC_SEARCH_LIBS([dlopen], [dl])
if test "$LIBS" != "$BAKLIBS"; then
LIBSSL_LIBS="$LIBSSL_LIBS -ldl"
fi
However, we're not using OpenSSL Engine support directly. If some
library user wants to initialize openssl's engine support, they should
be able to do that with OpenSSL itself, and then they should be able to
get libcrypto and/or libssl to use libdl directly.
On some minimal systems, libcrypto and libssl might be built without
engine support at all; in that case, libgetdns is adding a superfluous
dependency to the linker.
I don't know the what the getdns policy is about tweaking the files in
m4/, but maybe the following patch can be safely applied?
Thank you dkg! Great work!
Interestingly you've put the configuration of those two features at "context" level. Since both options (just like cookies) relate to upstreams, I think they should be configurable per upstream as well (perhaps using the context settings as the defaults, over-loadable by those upstream options). With my cookie implementation, I've implemented activation with an extension, but cookies also relate to upstreams, so perhaps they should be enableable per upstream as well (and have a global over-loadable setting in context).
Cheers,
-- Willem
This is a parameter to the getdns_context that tells the context how
much to pad queries that go out over TLS.
It is not yet functional in this commit, but the idea is to pad each
outbound query over TLS to a multiple of the requested blocksize.
Because we only have a set amount of pre-allocated space for dynamic
options (MAXIMUM_UPSTREAM_OPTION_SPACE), we limit the maximum
padding blocksize.
This is a simplistic padding policy. Suggestions for improved padding
policies are welcome!
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-04
Using the above spec, an intermediate resolver may forward a chunk of
the client's IP address to the authoritative resolver.
Setting edns_client_subnet_private to a getdns_context in stub mode
will indicate to the next-hop recursive resolver that the client
wishes to keep their address information private.
Sending DNS cookies was overwriting any existing options (DNS OPT) in
the outbound query.
Also, DNS cookies may not be the only option that gets set
per-upstream (instead of per-query).
This changeset establishes a set of per-query options (established at
the time of the query), and a buffer of additional space for adding
options based on the upstream is in use.
The size of this buffer is defined at configure time (defaults to 3000
octets).
Just before a query is sent out, we add the per-upstream options to
the query.
Note: we're also standardizing the query in tls too, even though we're
not sending any upstream options in that case at the moment
(edns_cookies are much weaker than TLS itself)
There is no clear reason to reject servers that don't have RSA certs.
We should accept ECDSA certs as well.
(also, clean up comments about opportunistic TLS)
unknown
Willem Toorop
Neil Cook
Claus Assmann
Sara Dickinson
Daniel Kahn Gillmor
Gowri
jad