Hi, Daniel Kahn Gillmor <d...@fifthhorseman.net> (2015-03-24): > On Tue 2015-03-24 16:01:20 -0500, Cyril Brulebois wrote: > > (Background: This issue has just been pointed out to me after a GNUnet > > conference. At least one developer there is interested in seeing a fix > > reach the archive.) > > > > 1. Not having looked too much at unbound yet, it seems to indeed > > support NSS instead of OpenSSL, so one might think about switching > > to it to get rid of (possible) OpenSSL license incompatibilities. > > > > 2. A softer way might be to build an NSS variant of the unbound library > > alongside with the OpenSSL (current/default) one, so that packages > > like GnuTLS can pull it instead, and deliver DANE support. > > > > 3. Yet another way might be to teach unbound to support GnuTLS in > > addition to OpenSSL and NSS, so that one can build a GnuTLS variant > > instead of an NSS one. > > > > Solution 1 seems harsh and could possibly break rdepends; solution 2 > > seems safer and only a (small?) matter of packaging; solution 3 might > > involve some bits of coding, and might cause tests entanglements in > > configure.ac. > > > > Thoughts? Should I look into patching unbound to support solution 2? > > I think option 2 is the simplest, shortest-path option for now, though > the idea that installing libgnutls28 brings in libnss3 as a dependency > seems rather ugly to me.
I can understand the feeling. I can work on this somewhen after D-I Jessie RC2 is out (hopefully this week). > option 3 would require probably using nettle as well as gnutls (for the > dnssec client verification) -- i'm not sure what sort of twisty maze of > dependencies or build-dependencies this creates, though :) Oh, nettle is an old friend (we use it as a sha1 implementation in xserver-xorg-core-udeb). About the “twisty maze” I was thinking about GOST and ECDSA disabling code in configure.ac, which depends on whether NSS is in use. Nothing dramatic though. http://sources.debian.net/src/unbound/1.4.22-3/configure.ac/#L703-L746 > libunbound should only depend on libssl for the purposes of outbound > DNS-over-TLS-over-TCP connections, right? the DNSSEC verification work > only needs to use libcrypto (or nettle, if we were to port it, which > would avoid the circularity). I really don't know. You can pretend somebody jumped on me asking whether I was part of Debian and mentioned this issue that has been tagged wontfix. That wouldn't be very far from what happened. ;) I can add nettlifying unbound to my ever growing to-do list, and see what codepaths are involved there. Maybe someone even did that work upstream already, I didn't check yet. Also, thanks for the swift reply. Mraw, KiBi.
signature.asc
Description: Digital signature