Fix cname issue ( bug #292545 ). EAPI2fy it

Package-Manager: portage-2.2_rc49/cvs/Linux x86_64

4 files changed, 185 insertions, 2 deletions

diff --git a/net-libs/adns/ChangeLog b/net-libs/adns/ChangeLog
index 5ed415486376..132fa4d74ba6 100644
--- a/net-libs/adns/ChangeLog
+++ b/net-libs/adns/ChangeLog
@@ -1,6 +1,13 @@
 # ChangeLog for net-libs/adns
 # Copyright 1999-2009 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/net-libs/adns/ChangeLog,v 1.34 2009/08/23 01:54:43 darkside Exp $
+# $Header: /var/cvsroot/gentoo-x86/net-libs/adns/ChangeLog,v 1.35 2009/11/10 13:53:36 hwoarang Exp $
+
+*adns-1.4-r1 (10 Nov 2009)
+
+  10 Nov 2009; Markos Chandras <hwoarang@gentoo.org> +adns-1.4-r1.ebuild,
+  +files/adns-1.4-cnamechain.patch:
+  Fix cname issue ( bug #292545 ). EAPI2fy it. Thanks to Alex Efros <powerman-asdf@yandex.ru>
+  for the attached patch.
 
   23 Aug 2009; Jeremy Olexa <darkside@gentoo.org> -files/1.1-gcc34.patch,
   -files/adns-gcc34.patch:
diff --git a/net-libs/adns/Manifest b/net-libs/adns/Manifest
index eda056abb5ce..a7b0d4ce358e 100644
--- a/net-libs/adns/Manifest
+++ b/net-libs/adns/Manifest
@@ -1,5 +1,7 @@
 AUX README.security 567 RMD160 3fafe8021bf616ad4853f76d30c289d17ccf9454 SHA1 4d9ece239f96f0cbc43003fc91ebd7fffd7ebe49 SHA256 ec1bf8c850d6245a69e5308bc71ec4c4d5dbeea7e7a1346bd5b810afd0a5d244
+AUX adns-1.4-cnamechain.patch 5261 RMD160 7ee965eacff15a0611d29fef919cba5db8d7ee94 SHA1 e81a9d3fd78f428a7193a85bfd29abb40e4de955 SHA256 416ebd92ee30bb65b45774bab64d5291ee6015f24e1d4295b458cdfa5104ef85
 DIST adns-1.4.tar.gz 252668 RMD160 ccff2111bfa3eb99e28d355d48e9e17333f34394 SHA1 87283c3bcd09ceb2e605e91abedfb537a18f1884 SHA256 717b92a39117a5d8b04ea7c652c630659c6eecb35211129a8cee95e6524ca9fe
+EBUILD adns-1.4-r1.ebuild 1138 RMD160 698061daa9b04104a0ab5319743fa03af1403497 SHA1 0fcccb02e4baf6c3c83a0997548b518d8c1ddfad SHA256 2658324a19945ddb59a54f1d06f84202521fdc16955baec3befb63b274618873
 EBUILD adns-1.4.ebuild 1033 RMD160 d54ea37aa6edb4bafcc4de2b38d52371a7116473 SHA1 b4eec995551f4543406de6ea1890e877200404f9 SHA256 6be8567b38e809cf9c76157a615cfc3bd98275e4666e19807dc9fc6b30def97d
-MISC ChangeLog 4023 RMD160 778a856c78c56cae36760a1d2916e4bec65935d8 SHA1 64fc1c15c0a1fce47e0322723f8b1027e01977cc SHA256 0b9cae29320de9a4dc43311005e4f5895cc6cca351b699cd413476992e92d9d8
+MISC ChangeLog 4282 RMD160 c69b3acb0b5277f7b96ac6b8d3e11b257bc7dd81 SHA1 0d6a8844d663031ba3d7d3d5f81588f968df9173 SHA256 a137b98cd5cf4d781fafc5372a5de914bdd45722c3559c42b1f2704aea407a7e
 MISC metadata.xml 290 RMD160 b9b86283c09349c8827faef7d3ef5f724a248e77 SHA1 ae1c8e62d75c94ff50b8a5391afb6008460963aa SHA256 380e26e9262298b9cb31e863a9ab641f6fbdc8c50bda2cf2e47fd399f9cb5e85
diff --git a/net-libs/adns/adns-1.4-r1.ebuild b/net-libs/adns/adns-1.4-r1.ebuild
new file mode 100644
index 000000000000..d6254366e3d8
--- /dev/null
+++ b/net-libs/adns/adns-1.4-r1.ebuild
@@ -0,0 +1,42 @@
+# Copyright 1999-2009 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/net-libs/adns/adns-1.4-r1.ebuild,v 1.1 2009/11/10 13:53:36 hwoarang Exp $
+
+EAPI="2"
+
+inherit eutils multilib toolchain-funcs
+
+DESCRIPTION="Advanced, easy to use, asynchronous-capable DNS client library and utilities"
+HOMEPAGE="http://www.chiark.greenend.org.uk/~ian/adns/"
+SRC_URI="ftp://ftp.chiark.greenend.org.uk/users/ian/adns/${P}.tar.gz"
+
+LICENSE="LGPL-2"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd"
+IUSE=""
+
+DEPEND=""
+RDEPEND=""
+
+src_prepare() {
+	epatch "${FILESDIR}"/${P}-cnamechain.patch
+}
+
+src_configure() {
+	CC=$(tc-getCC) econf || die "econf failed"
+}
+
+src_compile() {
+	emake AR=$(tc-getAR) RANLIB=$(tc-getRANLIB) || die "emake failed"
+}
+
+src_install () {
+	dodir /usr/{include,bin,$(get_libdir)}
+	emake prefix="${D}"/usr libdir="${D}"/usr/$(get_libdir) install || die "emake install failed"
+	dodoc README TODO changelog "${FILESDIR}"/README.security
+	dohtml *.html
+}
+
+pkg_postinst() {
+	ewarn "$(<${FILESDIR}/README.security)"
+}
diff --git a/net-libs/adns/files/adns-1.4-cnamechain.patch b/net-libs/adns/files/adns-1.4-cnamechain.patch
new file mode 100644
index 000000000000..4c87a1434660
--- /dev/null
+++ b/net-libs/adns/files/adns-1.4-cnamechain.patch
@@ -0,0 +1,132 @@
+[ADNS] Re: CNAME chains 
+Brad Spencer spencer at infointeractive.com 
+Mon, 28 Aug 2006 14:43:00 -0300 
+
+Previous message: CNAME chains 
+Next message: CNAME chains option 
+Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
+--pf9I7BMVVzbSWLtt
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+
+On Fri, Aug 25, 2006 at 11:36:04AM -0700, William Ahern wrote:
+> On Fri, Aug 25, 2006 at 09:39:01AM +0100, peter burden wrote:
+> > Hello,
+> >    Is there any way to make ADNS follow CNAME chains ?
+> > 
+> >    I have set the adns_qf_cname_loose query flag and it seems OK for a 
+> > single
+> >    CNAME - e.g. (output from 'dig')
+
+I posted a small patch back in 2003 that made changes to adns so that
+it would follow CNAME chains.  See
+
+http://www.chiark.greenend.org.uk/pipermail/adns-discuss/2003/001072.html
+
+The patch included in that post is against an old adns version, so I
+have attached my latest version of the patch to this message.  (I have
+not tested that the attached patch applied cleanly to the current adns
+source, but it may be slightly more in sync with the current version.)
+
+> CNAME chains are technically not allowed. Such chains are violations of the
+> specifications. Also, I believe MX host lookups returning CNAMEs (i.e. MX
+> yahoo.com -> A mail.yahoo.com -> CNAME foo) is also illegal.
+
+I have also been told that CNAME chains are illegal, but I can not
+find any actual text that says that a resolver should fail when it
+encounters them.  In fact, RFC 1034 Section 3.6.2 says:
+
+  Domain names in RRs which point at another name should always point at
+  the primary name and not the alias.  This avoids extra indirections in
+  accessing information.  For example, the address to name RR for the
+  above host should be:
+
+     52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
+
+  rather than pointing at USC-ISIC.ARPA.
+
+The above implies that CNAME chains are illegal, IMO.  But then, the
+next sentence is:
+
+  Of course, by the robustness principle, domain software should not
+  fail when presented with CNAME chains or loops; CNAME chains
+  should be followed and CNAME loops signalled as an error.
+
+This advice, coupled with the fact that CNAME chains exist in the
+wild, triggered me to create the patch in the first place.  My patch
+doesn't detect loops, but instead simply won't follow chains longer
+than a certain (hard-coded) size.
+
+Hope this helps!
+
+-- 
+------------------------------------------------------------------
+Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
+Systems Architect | InfoInterActive Corp. | A Canadian AOL Company
+
+--pf9I7BMVVzbSWLtt
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: attachment; filename="cname_chains.diff"
+
+Index: src/internal.h
+===================================================================
+RCS file: /iia/cvsroot/3rdParty/gnu/adns/adns-1.0/src/internal.h,v
+retrieving revision 1.3
+retrieving revision 1.4
+diff -u -p -r1.3 -r1.4
+--- src/internal.h	2 Oct 2003 17:01:46 -0000	1.3
++++ src/internal.h	2 Oct 2003 17:14:29 -0000	1.4
+@@ -206,6 +206,9 @@ struct adns__query {
+   int cname_dglen, cname_begin;
+   /* If non-0, has been allocated using . */
+ 
++  int cname_alias_hops_left;
++  /* The number of cname alias hops we will allow */
++
+   vbuf search_vb;
+   int search_origlen, search_pos, search_doneabs;
+   /* Used by the searching algorithm.  The query domain in textual form
+Index: src/query.c
+===================================================================
+RCS file: /iia/cvsroot/3rdParty/gnu/adns/adns-1.0/src/query.c,v
+retrieving revision 1.3
+retrieving revision 1.4
+diff -u -p -r1.3 -r1.4
+--- src/query.c	2 Oct 2003 17:01:47 -0000	1.3
++++ src/query.c	2 Oct 2003 17:14:29 -0000	1.4
+@@ -63,6 +63,8 @@ static adns_query query_alloc(adns_state
+ 
+   qu->cname_dgram= 0;
+   qu->cname_dglen= qu->cname_begin= 0;
++  /* Allow CNAME chains up to some sane limit */
++  qu->cname_alias_hops_left = 10;
+ 
+   adns__vbuf_init(&qu->search_vb);
+   qu->search_origlen= qu->search_pos= qu->search_doneabs= 0;
+Index: src/reply.c
+===================================================================
+RCS file: /iia/cvsroot/3rdParty/gnu/adns/adns-1.0/src/reply.c,v
+retrieving revision 1.3
+retrieving revision 1.4
+diff -u -p -r1.3 -r1.4
+--- src/reply.c	2 Oct 2003 17:01:47 -0000	1.3
++++ src/reply.c	2 Oct 2003 17:14:30 -0000	1.4
+@@ -191,12 +191,13 @@ void adns__procdgram(adns_state ads, con
+       if (qu->flags & adns_qf_cname_forbid) {
+ 	adns__query_fail(qu,adns_s_prohibitedcname);
+ 	return;
+-      } else if (qu->cname_dgram) { /* Ignore second and subsequent CNAME(s) */
++      } else if (qu->cname_dgram && --(qu->cname_alias_hops_left) <= 0) { /* Don't follow "too long" CNAME chains */
+ 	adns__debug(ads,serv,qu,"allegedly canonical name %s"
+-		    " is actually alias for %s", qu->answer->cname,
++		    " is actually alias for %s and aliases too deep",
++                    qu->answer->cname,
+ 		    adns__diag_domain(ads,serv,qu, &qu->vb,
+ 				      dgram,dglen,rdstart));
+-	adns__query_fail(qu,adns_s_prohibitedcname);
++	adns__query_fail(qu,adns_s_norecurse);
+ 	return;
+       } else if (wantedrrs) { /* Ignore CNAME(s) after RR(s). */
+ 	adns__debug(ads,serv,qu,"ignoring CNAME (to %s) coexisting with RR",
+
+--pf9I7BMVVzbSWLtt--