On Mar 9, 2013, at 5:14 PM, Daniel Stenberg wrote:

> 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.
>

The dependency is from libval to libsres (libval uses libsres). I tried building curl on osx, and while I am using shared libraries I still needed to link against both -lval and -lsres to get things to work as expected. I'll look into creating a pkg-config setup for the dnsval package if that'd be useful to you.

> 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?)

dnsval is the name that we use to refer to the combination libval and libsres. The svn repo itself is at https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator while the COPYING file is at https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/COPYING

I see your point about the COPYING file, we'll include it in the next release of the dnsval package.

>
>> 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?
>

This is probably related to the configure.ac clean-up. In cases where curl is built using pthreads it would be good to link against libval-threads. In other cases it is fine to link against -lval and there will not be any dependency on pthreads.

>> 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!)
>

Fair enough.

>> 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.
>

okay, I'll see if I can figure out a more generic approach. If you have any specific suggestions, feel free to throw them my way.

>
> (Let me dive into a little related side-story here...)
...
> can you tell us a reason why libval is better
>

I haven't done an extensive feature comparison of our library with other libraries but the ability to send out asynchronous queries from a single thread is certainly one reason, if the other libraries do in fact require additional threads.

Our library was probably the first DNSSEC stub validator implementation that came about for the current DNSSEC specification. We started with an API (the draft referenced earlier) and built our implementation around it so that we could support a range of applications - some apps that would need a simple validated/not-validated answer, while others that would need more control over validation processing or more detail on the types of failure encountered during validation processing. There's probably more worked examples of applications that have been made DNSSEC-capable using libval than other libraries at present, but the library itself is not wildly popular I'll admit.

>
>> 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?

Correct, currently only supports select() though - not poll().

> 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.
>

A basic manual page should now be on http://www.dnssec-tools.org/docs/tool-description/libval_async.html (the text was mostly extracted from the api draft above).

Thanks!
Suresh

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-12