On Sun, Dec 06, 2015 at 08:50:55AM -0500, The Wanderer wrote: > On 2015-12-06 at 07:01, David Kalnischkies wrote: > > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote: > > (as I am sightly lying, it is actually possible – just not very > > accessible for a user and it would have issues so I am not going to > > say how here) > > In public, where it can be discovered later by people who won't know or > be in a position to even judge (much less handle) those issues, you > mean? I am not going to mention it because that makes people end up using it because "its faster" or other non-sense. They will eventually find it anyway in a posting by some 'experts' on the interwebs like it is with other topics involving "downloading stuff" but if all the security bugs eventually catch up to them I at least can honestly say I had nothing to do with it… Anyway: It isn't too hard to figure it out by yourself if someone really wants to, but if this someone isn't motivated enough to figure it out, it is unlikely to be a good idea: The problem is in various short-cuts apt is using to avoid costly hashsum calculations: If it has an 'old' Release file on disk and is asked to download the Contents file for amd64, it opens the old Release file and compares with the already downloaded new Release file: If the hashsums match apt doesn't bother asking the server for the Contents file as even in the best case it would just get a "you already have the newest file" response from the server (and some servers do not support this, so they send us the entire content again, which we have to deal with and in the end discard – total waste of time and bandwidth). The same happens for all the other files, like Packages, Sources, Translations, … If you disable one of these indexes temporarily (and disable list cleaning) [and yes, that is the "solution" blueprint], the next run in which the index is enabled again will believe that the index file is as up-to-date as the Release file is – which isn't correct, so that you have after an update not the latest of all files but some strange mixture until the files change again. That could take a while and confuse the heck out of pdiff – and if this not-really-uptodate happens to effect security updates you are unprotected for longer than it would be needed… Beside the obvious fix (calculating hashes all the time which kills performance) we could invent other ways of dealing with this, but that is a bunch of design and code work – which, personally, I would like to avoid if there isn't a good reason for it as that time could be invested in other more pressing bugs/features. The rest, others have hopefully answered to your satisfaction. I just have to add that while conceptually similar, it isn't via hooks, but src:apt >= 1.1~ allows other packages to declare that they want libapt-based front-ends to acquire files for them. apt-file is just the first example. DEP11 software is likely to follow 'shortly'. Technical details can be found here: https://anonscm.debian.org/cgit/apt/apt.git/tree/doc/acquire-additional-files.txt (please, before anyone commenting on this, read the doc first – its very likely the problem you see with it is not only covered in the docs but also not existing in reality due to practical limitations of what apt can be told to acquire). The point is that apt-file (and all other tools requiring Debian metadata) can drop all of its code responsible for getting files from a Debian repository over potentially very hostile channels, which isn't an easy task – even if you ignore security aspects as apt-file did – and instead outsource it to libapt who needs to do that anyway and has decades of features and experience with it already. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature