Package: squid-deb-proxy-client
Version: 0.8.9
Severity: normal
Tags: patch
Hi!
I must admit: I have a broken setup. So maybe this could be argued as
"garbage in, garbage out". But hear me out before you discard this
one. :)
In my home network, I did some tests to setup apt-cacher-ng on my
workstation, then deployed the results on the real local server. As a
result, I have *two* apt-cacher-ng services (or so I thought), running
in the local network.
It turns out the workstation one isn't working very well and is
refusing connexions:
nc: unable to connect to address 192.168.0.175, service 3142
Oops. Not sure what happened there. Oh well. But
squid-deb-proxy-client don't care right? He'll survive this, there's
this timing thing to rate proxies and chose the fastest one and
all. Wrong! It actually completely fails to find the right proxy,
because the above misconfiguration triggers an exception on the client
side:
$ apt-avahi-discover
error: uncaptured python exception, closing channel <AptAvahiClient>
('fd05:5f2d:569f::fc3', 3142, 0, 0): 9223372036854775807 (<class
'socket.error'>:[Errno 111] Connection refused
[/usr/lib/python2.7/asyncore.py|read|83]
[/usr/lib/python2.7/asyncore.py|handle_read_event|446]
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel <AptAvahiClient>
('192.168.0.175', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno
111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83]
[/usr/lib/python2.7/asyncore.py|handle_read_event|446]
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
http://192.168.0.3:3142/
Boom. Here you can see the correct proxy URL is shown, but only
*after* uncaught exceptions are dumped on the console. APT, naturally,
freaks out and doesn't find the proxy and falls back to just doing a
direct connexion.
This could be fine, except it means that a local proxy can be "hidden"
with a deliberately misconfigured Avahi service. Now I don't think
this is a security issue per se - merely an annoyance. But it *does*
make debugging quite hard, because everything seems fine from the
client's perspective: the real server is properly configured and
answering requests. It's only when you run that script by hand that
you realize you left that other service running.
I have found, mostly through trial and error, that the following patch
fixes the issue:
--- apt-avahi-discover 2013-09-20 08:04:12 +0000
+++ apt-avahi-discover 2017-08-01 01:21:12 +0000
@@ -48,6 +48,11 @@
self._time_init = time.time()
self.time_to_connect = sys.maxint
self.address = addr
+ def handle_connect_event(self):
+ try:
+ asyncore.dispatcher.handle_connect_event(self)
+ except Exception as e:
+ DEBUG("error from dispatcher: %s" % e)
def handle_connect(self):
self.time_to_connect = time.time() - self._time_init
self.close()
I originally tried to add exception handlers in __init__ and
handle_connect but for some reason, handle_connect_event is where the
exception is raised. Go figure.
With the above, my APT client works correctly even if there's a
misbehaving Avahi server out there.
Thanks!
-- System Information:
Debian Release: 8.9
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages squid-deb-proxy-client depends on:
ii apt 1.0.9.8.4
ii avahi-utils 0.6.31-5
ii python 2.7.9-1
squid-deb-proxy-client recommends no packages.
squid-deb-proxy-client suggests no packages.
-- no debconf information
