On Mon, 2006-11-20 at 10:16 +0100, Andreas Barth wrote: > * Franz Pletz (fpletz@franz-pletz.org) [061119 21:06]: > > On Sun, Nov 19, 2006 at 07:07:03PM +0100, Reinhard Tartler wrote: > > > Why don't you install a line like > > > > > > > e.g. deb http://127.0.0.1:1618/debian main contrib non-free > > > > > > in /etc/apt/sources.list.d, and be done with it? That's what I'd > > > call > > > zero config. > > > > > > You would have to convince apt to prefer apt-zeroconfig sources > > > over > > > 'regular' HTTP sources, so that it only uses the slow line when the > > > package couldn't be found in the neighbourhood. I believe this could be > > > tweaked be tuning /etc/apt/preferences. If not, you would have to hack > > > up apt a bit. > > > > We also pondered with that idea, but with this configuration modifying > > apt is definitely required. Apt associates a server to every package > > and version where to get the debs from. We are not building package > > lists from all hosts in the network because this would compromise the > > security of the whole network. > > Two questions: > > 1. Why don't you add the appropriate proxy-line to to apt via apt.conf.d > (e.g. as conffile, so you don't have to care about that later on)? This is basically what our proxy mode supports, but we haven't yet automated the process of adding apt-zeroconf to apt. We should probably do that, right. We are thinking about using debconf for this to let users a choice how may like to use azc only for some of there apt sources. > 2. What security threats do you see? Since there is a lot of work done on apt security most cases are handled right through apt itself. But we maybe should azc let do some checks: Imagine there is someone in the network who offers corrupted files and you download through azc. apt will not install them because of missmatching hashes (as long nobody is able to crack md5, sha at once - but this is not a azc specific problem). So you fail to install the stuff you wanted and the you don't know why - and especially not who is to blame. If you try to install the package again you will fail again as log as there is only on person who offers the file. As long as we don't check the package within azc its not possible to react automatic to an corrupted file since azc doesn't recognizes that apt fails to install a file. But this would be good - for example for ignoring the node at further file searches to avoid to download the same corrupted file again. This would add some load to azc since the checking cost cpu and hd time so it should be optional but turned on by default. I hope in the next release there will be a proper logging system. With that you can figure out who offered the corrupted file by grep'ing the log files. Not official reps are always a security risk... especially those that contain... * Packages without hashes * Pkgs without sign * PkgLists without sign For now we don't handle package lists (and/or pdiffs) with azc - they are always fetched from the fallback-server - but may add it this to azc in future. Since pkg lists are also signed it shouldn't be a security hole. At all its much more complicated to cache the pkg lists so this will be done one day in future - perhaps. Florian Ludwig
Attachment:
signature.asc
Description: This is a digitally signed message part