* Michael Banck: > On Thu, Dec 18, 2008 at 12:51:34PM +0100, Bastien ROUCARIES wrote: >> On Thu, Dec 18, 2008 at 12:35 PM, Bjørn Mork <bm...@dod.no> wrote: >> > Florian Weimer <f...@deneb.enyo.de> writes: >> >> > I would very much like this library to become the *only* WPAD >> > implementation anywhere. Hopefully eventually with some ability to >> > define local policies, where the default Debian policy could be very >> > strict. E.g. "Never trust DNS for WPAD", or "Never use WPAD at all". >> >> I tend to agree, we have not forbidden root to do rm -arf . >> It is the same, it is a policy problem. With current libproxy, could root >> forbid the use of WPAD, even if user ask it? > > Dan Winship, one of the libproxy authors, replied: > > | - The fact that it's broken doesn't change the fact that lots of > | sites use it
I think the question is if there are many sites where you cannot reach the WWW without performing full WPAD (including DNS devolution). > | - It's already implemented by other programs in the distro anyway > | (notably Firefox) This is incorrect. Firefox does not implement WPAD, according to this comment in the source code: } else if (mProxyConfig == eProxyConfig_WPAD) { // We diverge from the WPAD spec here in that we don't walk the // hosts's FQDN, stripping components until we hit a TLD. Doing so // is dangerous in the face of an incomplete list of TLDs, and TLDs // get added over time. We could consider doing only a single // substitution of the first component, if that proves to help // compatibility. Indeed, the critical part of WPAD is DNS devolution. (The last sentence is overly optimistic, though.) The DNS root operators probably wouldn't want us to roll out Mozilla's http://wpad/wpad.dat-style partial WPAD, either, because it creates useless traffic at the root. Traffic which can't even be offloaded similarly to the reverse lookups for RFC 1918 by the AS 112 project because it's well within the security perimeter of the global Internet. (Iceweasel doesn't this partial WPAD approach by default, so we have that covered.) > | > | - Its use in libproxy can be disabled system-wide by the > | administrator > | > |I think in current libproxy WPAD is enabled by default though. We should > |make sure that's changed. The TLD/SLD blacklist in libproxy for DNS devolution is incomplete. It should use the public suffix list from Mozilla. Maybe it should even be split into a separate package, so that it can be updated separately. The main risk is that someone has got a computer name like pc251.example.co.nz, which devolves to wpad.example.co.nz and wpad.co.nz, the latter being the problem. There's also a concern among large organizations that DNS devolution breaks separation of administrative domains along DNS domains (that is, deparment1.example.com is affected by a delegation of wpad.example.com by a second department). Not enabling WPAD with DNS devolution goes a long way towards dealing with this mess. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org