This is a heads-up in case anyone else stumbles across this problem and (like us) ends up spending a lot of time trying to figure out what has gone wrong. The matter has been seperately reported to the SuSE Security contact address (last Friday so they may not have had a chance to investigate it yet). In short, if you're using Squid on SuSE 9.2 (others may be affected but this is the only SuSE version we've checked) with the official Squid RPMs, the latest security updates will break cache digests thus render proxy peering one-way only (that is, your proxy can fetch/use digests but cannot share its own digest with other peers). The symptom is that a seemingly perfectly good Squid config (indeed, one that was previously working) will start reporting "404 Not Found" for every cache digest request, even if the proxy has been running for days (despite the error message, the digest has been built but Squid is refusing to store it locally). Looking through some source RPMs on the 'net, the problem appears to have been introduced around release 6.8 of the Squid RPM (ie., February) and is still present in release 6.10 (April): squid-2.5.STABLE6-6.10 The culprit appears to be an old version of this security patch: squid-2.5.STABLE7-response_splitting.patch The Squid team released an earlier version (used by SuSE in the security update) that broke cache digests, then later released an updated version to correct the problem (alas, this correct version of the patch has not yet found its way into the SuSE Squid updates available via YOU). The matter can be seen discussed in this thread (note specifically the first, penultimate and last messages in this thread): http://www.squid-cache.org/mail-archive/squid-users/200501/0798.html If you compare the version of this patch in the SuSE source RPM to the version available on the Squid Web site, the newer version of the patch adds an extra line to the store digest code in order to fix the broken cache digests thus get bi-directional peering working again. Hope this saves someone some time/effort... Cheers..
participants (1)
-
David J N Begley