From owner-freebsd-ports@FreeBSD.ORG Tue Jun 18 07:07:30 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A23E3B1 for ; Tue, 18 Jun 2013 07:07:30 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id F36341CA7 for ; Tue, 18 Jun 2013 07:07:29 +0000 (UTC) Received: from nskntcmgw08p ([61.9.169.168]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20130618050724.YUSG21423.nskntmtas01p.mx.bigpond.com@nskntcmgw08p> for ; Tue, 18 Jun 2013 05:07:24 +0000 Received: from johnny.reilly.home ([124.188.162.192]) by nskntcmgw08p with BigPond Outbound id ph7D1l00849NTNc01h7QVX; Tue, 18 Jun 2013 05:07:24 +0000 X-Authentication-Info: Submitted using ID areilly@bigpond.net.au X-Authority-Analysis: v=2.0 cv=FNuZNpUs c=1 sm=1 a=E3UA96qjU4/DKYBP5EH6OA==:17 a=wom5GMh1gUkA:10 a=bLIE5C9F5wIA:10 a=kj9zAlcOel0A:10 a=Sv2sojjTAAAA:8 a=ll3cvjU_-i4A:10 a=OjbJKbgLAAAA:8 a=rni8XLtOEg2YSEgb3wMA:9 a=CjuIK1q_8ugA:10 a=E3UA96qjU4/DKYBP5EH6OA==:117 Date: Tue, 18 Jun 2013 15:07:13 +1000 From: Andrew Reilly To: ports@freebsd.org Subject: distfile fetching vs ISP "site-help" spoofing: any suggestions? Message-ID: <20130618050713.GA27806@johnny.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 07:07:30 -0000 I've just tried to portupgrade after a three-month hiatus and noticed a problem with the libgcrypt distfile checksum that didn't go away after my usual strategy of waiting for a couple of days, re-syncing the ports tree and trying again. Closer inspection and a hint from a google search revealed that the first-level problem is that the wrong file had been fetched: it was a short HTML file, rather than the expected tar.bz2 file. How did that happen? Apparently my ISP (Bigpond, in Australia) has recently turned on a "site-helper" mechanism that spoofs any site for which a DNS-lookup fails. That is, there are now no "missing" or expired sites. In this case, the first item in the ports/Mk/bsd.sites.mk list used by the security/libgcrypt Makefile is gnupg.org.favoritelinks.net which does not (any longer?) resolve. I've arranged to proceed by deleting the line in bsd.sites.mk, which allowed the fetch to succeed. This seems a bit lame though, because perhaps that site will come back one day. Seems like a fragile, non-scaling approach. It might be possible to subvert my ISP's evil helpfulness by pointing my DNS requests further upstream, but that might prevent the government from blocking my access to things it considers distasteful, and I'm not sure I want to go there just yet. Anyone have any suggestions or best practices? Should I try to raise a PR against bsd.sites.mk or security/libgcrypt? Cheers, -- Andrew