Default to not caching a deb instead of 403'ing.

Bug #952364 reported by Jorge Castro on 2012-03-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone
squid-deb-proxy (Ubuntu)

Bug Description

Right now if you install s-d-p by default it's mirror ACL doesn't include some repositories. People need to add them explicitly.

This results in 403 errors on update. Is there a way we can just not cache the debs instead of spitting out an error?

Michael Vogt (mvo) on 2012-04-02
Changed in squid-deb-proxy (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package squid-deb-proxy - 0.6.2

squid-deb-proxy (0.6.2) precise; urgency=low

  [ Michael Vogt ]
  * squid-deb-proxy.conf:
    - use "aufs" instead of "ufs" for the cache directory. Thanks
      to Robert Colins for this suggestion

  [ Robie Basak ]
  * squid-deb-proxy.conf: always refresh Packages and Release files.
    (LP: #952364)
 -- Michael Vogt <email address hidden> Mon, 02 Apr 2012 22:09:12 +0200

Changed in squid-deb-proxy (Ubuntu):
status: In Progress → Fix Released
Michael Vogt (mvo) wrote :

Making the access unrestricted should be easy with the following lines:

=== modified file 'squid-deb-proxy.conf'
--- squid-deb-proxy.conf 2012-04-02 20:01:03 +0000
+++ squid-deb-proxy.conf 2012-04-02 20:23:31 +0000
@@ -79,7 +79,7 @@
 # allow access only to official ubuntu mirrors
 # uncomment the third and fouth line to permit any unlisted domain
 http_access deny !to_ubuntu_mirrors
-#http_access allow !to_ubuntu_mirrors
+http_access allow !to_ubuntu_mirrors

 # don't cache domains not listed in the mirrors file
 # uncomment the third and fourth line to cache any unlisted domains

from irc:
<mvo> jcastro: so the only reason unrestricted access is not enabled by default currently is to allow this to be dropped into a already restricted network without opening up generic http access via this squid-deb-proxy, I guess it could be argued that this is something that a admin should restirct himself/herself and that convinence is better. or we add another debconf question, but that is not very discoverable either :/
<jcastro> I think not having an unrestricted proxy is reasonable; ideally the proxy saying "fine, go download from this random repository, I will neither help you nor hinder you" sounds like a good middle ground to me
<rbasak> jcastro: the security issue isn't whether it caches your deb or not (pretty minor, just a DoS of the cache), but whether you can get the deb or not (pretty major - could subvert an existing security policy controlling general access). I favour a debconf option.
<mvo> jcastro: right, my thinking (but bear in mind that I'm not a sysadmin :) was that the proxy host has usually different network restrictions than the regular clients, so opening up the proxy sounds potentially dangerous to me
<jcastro> mvo: we should just ask elmo what to do. :) Or perhaps grab a -security guy at UDS or something, whatever works for me.
<mvo> jcastro: yeah, someone more experienced than me on this and I will happly implement whatever they suggest, for now I'm totally fine with a debconf prompt
 jcastro: note that I want this to be as simple as possible really

Michael Vogt (mvo) on 2012-04-03
Changed in squid-deb-proxy (Ubuntu):
status: Fix Released → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers