On Fri, 8 Mar 2013, Suresh Krishnaswamy wrote:

>> A. The configure.ac check should check for the required libs properly using
>> correct autoconf mechanisms. What's the reason you need to specify
>> -lsres and -lpthread when you're "only" using the val-threads lib? For
>> static linking?
>
> The dnsval component is actually split into a set of two libraries - libval
> and libsres.

Okay, but surely one of them uses the other (X uses Y)? If that is the case
and we use the shared version, linking with X is enough for curl as then it'll
link with Y by itself. (Unless we build statically, but if we do I suspect we
would also have to specify more libraries such as the crypto libraries etc.)

Ideally your lib would provide a pkg-config setup so that our configure script
gets an easier task. But sure, I'll help out and work on making something.
I'll see what I can do.

This lib is called 'dnsval' ? Where's the public svn repo? (Also, the tarball
doesn't include licensing information but refers to 'COPYING' in another
package, which I think is unfortunate and rather hostile. why not just
include a copy in this tarball too?)

> libval in turn can be built with or without thread support. When built with
> thread support (we attach the -threads suffix to the library name in that
> case) we also need pthread support.

Well, the same argument as above goes for pthread... So when does it require
pthread or not? It looks like you went for the -pthread naming in the
configure patch, so what's the difference for us? Why would we want it pthread
enabled?

> The change to configure.ac was a quick way to get the HAVE_DNSVAL_DANE
> definition in place without diving too deep into the existing configure
> script structure. I agree that it would be better to have a more robust set
> of checks here.

Not only _can_ it be made better, I can't accept the patch without a solid
configure check. (Because otherwise an angry mob of users will come chasing us
with pitchforks!)

> libval uses libcrypto internally for all its DNSSEC-related crypto checks,
> so currently the patch implicitly relies on openSSL for DANE support.

Well sure, your lib would use openSSL. It doesn't mean that anything else does
as long as your API doesn't expose anything OpenSSL-specific etc.

> Given the current dependency on openSSL I wasn't sure if there was a way to
> move the DANE checks in curl to a more generic location. That said, we are
> looking to add support for other crypto libraries in libval in the near
> future.

You could start with moving out the DANE-checking function(s) out of ssluse.c
into perhaps sslgen.c, and then just call the function from ssluse.c. Then we
can add calls to that function from each SSL backend. Or else we figure out an
even more generic approach that avoids us having to change all backends to add
support for this.

>> D. val_getdaneinfo() seems like a blocking function call. Since it involves
>> DNS and what not, that could potentially take a very long time. Is there
>> any non-blocking alternative APIs or what can we do to avoid long blocks?
>>
>> Is there documentation somewhere for the lib?
>
> The val_dane_submit() function provides the asynchronous lookup capability
> and there's sample code in the validator/apps directory of the dnsval
> package that illustrates its use. I've also put up a man page for the
> DANE-related functions at
> http://www.dnssec-tools.org/docs/tool-description/val_getdaneinfo.html

(Let me dive into a little related side-story here...)

Only minutes after I (in sheer joy!) tweeted about your initial DANE patch
people responded to me and said that we should rather base DANE stuff on
libunbound instead of libval (it isn't really clear to me exactly what the
reasons are or if they are right or not). It had the effect on me that I was
immediately made aware of the fact that we have at least two "competing"
library alternatives to choose from for this.

I figure you're the author or at least contributor to libval, but can you tell
us a reason why libval is better than libunbound for our purposes?

... anyway, when I got those comments I checked out libunbound's API (as they
contrary to libval provided API docs that were online) and I was deeply
dissappointed when I learned that they think a non-blocking API is made with
threads and firing off a sub-thread that calls a callback when it is done.
Designing a non-blocking API with a thread and a callback on completion is
(should I really use this word?) STUPID. (Hopefully someone will tell me I
missed something in the documentation and that they offer select/poll on
complettion.)

> A general description of the asynchronous lookup API is at
> http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-09

Reading this, it gives me the impression it will give me file descriptors etc
to wait for in good old unix-style, right? That seems EXACTLY what we want and
need!

> I'll try and also create a manual page version for the async functions in a
> little bit.

That'd be great! I think it makes a lot of sense to make use of this
non-blocking API already from the start. We do after all want to allow many
parallell SSL connections and DANE checks within a single thread. As we can
handle the normal CA-style cert checks non-blocking already it would be a
major setback to have to punish DANE-using connections with slow synchronous
functions!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html