From owner-freebsd-stable@freebsd.org Wed Dec 23 15:42:08 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C936A4F729 for ; Wed, 23 Dec 2015 15:42:08 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1EEF1B17 for ; Wed, 23 Dec 2015 15:42:07 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id tBNFg7sC098386 for ; Wed, 23 Dec 2015 07:42:13 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> References: <567A92BD.5010105@ish.com.au>, <28b3786fbb6baa6619c6ff9662113650@ultra-secure.de> From: "Chris H" Subject: Re: freebsd-update incorrect hashes Date: Wed, 23 Dec 2015 07:42:13 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <62d141c46b3f32c3f81d7faf877ac2af@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 15:42:08 -0000 On Wed, 23 Dec 2015 14:22:51 +0100 rainer@ultra-secure.de wrote > Am 2015-12-23 13:25, schrieb Aristedes Maniatis: > > I've had problems with freebsd-update for many years now. It is by far > > the least reliable component of FreeBSD since I started with the > > operating system back at 3.4 in 1999. > > > > Anyhow, I'm usually able to get past the exceedingly slow downloads > > and errors to the upgrade process, but this time nothing I do will get > > me to the end. I've tried deleting /var/db/freebsd-update but several > > hours later I was at the same place again. The internet link is fast, > > but with a web proxy in this location, some downloads are slightly > > delayed while the virus scanner on the proxy does its thing. Perhaps > > 3-5 seconds delayed. > > > > The problem is phttpget or the proxy, depending on the point of view. > > Some proxies have (had) problems with the pipelined http requests that > phttpget seems to use. > > apt (Debian/Ubuntu) has, too - but they can be disabled altogether > there. > > http://webcache.googleusercontent.com/search?q=cache:OwcOVJamJOoJ:https://www > .astaro.org/gateway-products/web-protection-web-filtering-application-visibil > ity-control/55213-http-pipelining-broken-after-upgrade-utm-9-3-a.html+&cd=1&h > l=de&ct=clnk&gl=ch > > IMO, there should be an option to use wget instead of phttpget. Or at > least disable the request-pipelining. > There was a PR with patches floating around to make freebsd-update use > wget, but it never gained traction. > > Also, didn't phttpget have problems with proxies needing authentication? > I usually have authentication at the proxy disabled for *.freebsd.org > for this reason. I concur, to the extent that phttpget[1] runs pretty much "blind". As it it, phttpget blindly accepts any 200 response, and drops any other response. What does this mean? Why would/could this be a problem? It slurps all 200 responses; meaning; if the response is not a file, but a web page asking for some kind of response from you, *that's* what phttpget downloads. It also means that if the 200 response is a web page indicating that the file you are looking for has moved, and has a link to it's new location. Then *that's* what phttpget downloads. The possibility's go on, and on. But you get the picture. :) --Chris [1] http://www.daemonology.net/phttpget/