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.
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 :)
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).
--dkg
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
