Date: Tue, 18 Jun 2013 09:07:28 +0100 From: Matthew Seaman <matthew@freebsd.org> To: freebsd-ports@freebsd.org Subject: Re: distfile fetching vs ISP "site-help" spoofing: any suggestions? Message-ID: <51C01540.4030009@freebsd.org> In-Reply-To: <20130618050713.GA27806@johnny.reilly.home> References: <20130618050713.GA27806@johnny.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18/06/2013 06:07, Andrew Reilly wrote: > 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. Your ISP is screwing you over. Complain, loudly. Vote with your feet. There was a big to-do about this sort of behaviour around the BIND community a few years ago, and the overwhelming consensus was that not returning NXDOMAIN for a non-existent domain was simply wrong and an evil plot to monetize people's inaccurate typing. > 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. Run your own recursive resolver instance. The default config for named in base is set up for this: pretty much all you need to do is turn on named and modify /etc/resolv.conf to say 'localhost' for your nameserver. Or use the Google nameservers -- 8.8.8.8 and 8.8.4.4 > Anyone have any suggestions or best practices? > > Should I try to raise a PR against bsd.sites.mk or security/libgcrypt? No, don't do that. There's nothing wrong with bsd.sites.mk. The problem here is local to your site / ISP, and that's where you should look for a solution. Cheers, Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C01540.4030009>