Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.8 2015-12-19T22:04:34Z 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore 2015-11-04T17:04:03Z David Kalnischkies david@kalnischkies.de 2015-10-25T11:35:00Z urn:sha1:2b0660b537581e9e65180e4cf1a94d763fd66847 -q is for logging and -qqq (old -qq) basically kills every output expect errors, so there should be a way of declaring a middleground in which the output of e.g. 'update' isn't as verbose, but still shows some things. The test framework was actually making use of by accident as it ignored the quiet level in output setup for apt before. Eventually we should figure out some better quiet levels for all tools… 2015-09-14T13:22:19Z David Kalnischkies david@kalnischkies.de 2015-09-14T00:26:13Z urn:sha1:63c7141275c8c5c0f6e60f5242785e50cabaf2a0 Not all tests work yet, most notable the cdrom tests, but those require changes in libapt itself to have a proper fix and what we have fixed so far is good enough progress for now. Git-Dch: Ignore 2015-08-14T10:38:18Z Julian Andres Klode jak@debian.org 2015-08-14T09:49:45Z urn:sha1:b381a482eab0fc7b65b63cf0512ef1f97d775e34 This enables more fine grained control over such exceptions. 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-08-09T17:01:49Z urn:sha1:0efb29eb36184bbe6de7b1013d1898796d94b171 I never understood why there is an extra newline in those messages, so now is as good time as any to drop them. Lets see if someone complains with a good reason to keep it… 2015-06-11T08:56:31Z David Kalnischkies david@kalnischkies.de 2015-06-11T08:56:31Z urn:sha1:1da3b7b8e15b642135b54684e70a0c271471f07a It is a rather strange sight that index items use SiteOnly which strips the Path, while e.g. deb files are downloaded with NoUserPassword which does not. Important to note here is that for the file transport Path is pretty important as there is no Host which would be displayed by Site, which always resulted in "interesting" unspecific errors for "file:". Adding a 'middle' ground between the two which does show the Path but potentially modifies it (it strips a pending / at the end if existing) solves this "file:" issue, syncs the output and in the end helps to identify which file is meant exactly in progress output and co as a single site can have multiple repositories in different paths. 2015-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-08T13:22:01Z urn:sha1:8d041b4f4f353079268039dcbfd8b5e575196b66 If we have a file on disk and the hashes are the same in the new Release file and the old one we have on disk we know that if we ask the server for the file, we will at best get an IMS hit – at worse the server doesn't support this and sends us the (unchanged) file and we have to run all our checks on it again for nothing. So, we can save ourselves (and the servers) some unneeded requests if we figure this out on our own. 2015-06-07T07:42:53Z David Kalnischkies david@kalnischkies.de 2015-05-19T08:40:55Z urn:sha1:58702f8563a443a7c6e66253b259c2488b877290 If we e.g. fail on hash verification for Packages.xz its highly unlikely that it will be any better with Packages.gz, so we just waste download bandwidth and time. It also causes us always to fallback to the uncompressed Packages file for which the error will finally be reported, which in turn confuses users as the file usually doesn't exist on the mirrors, so a bug in apt is suspected for even trying it… 2015-05-18T20:15:06Z David Kalnischkies david@kalnischkies.de 2015-05-18T20:15:06Z urn:sha1:6bf93605fdb8e858d3f0a79a124c1d39f760094d Valid-Until protects us from long-living downgrade attacks, but not all repositories have it and an attacker could still use older but still valid files to downgrade us. While this makes it sounds like a security improvement now, its a bit theoretical at best as an attacker with capabilities to pull this off could just as well always keep us days (but in the valid period) behind and always knows which state we have, as we tell him with the If-Modified-Since header. This is also why this is 'silently' ignored and treated as an IMSHit rather than screamed at the user as this can at best be an annoyance for attackers. An error here would 'regularily' be encountered by users by out-of-sync mirrors serving a single run (e.g. load balancer) or in two consecutive runs on the other hand, so it would just help teaching people ignore it. That said, most of the code churn is caused by enforcing this additional requirement. Crisscross from InRelease to Release.gpg is e.g. very unlikely in practice, but if we would ignore it an attacker could sidestep it this way. 2015-05-13T14:09:12Z David Kalnischkies david@kalnischkies.de 2015-05-13T14:09:12Z urn:sha1:8eafc759544298211cd0bfaa3919afc0fadd47d1 Not all servers we are talking to support If-Modified-Since and some are not even sending Last-Modified for us, so in an effort to detect such hits we run a hashsum check on the 'old' compared to the 'new' file, we got the hashes for the 'new' already for "free" from the methods anyway and hence just need to calculated the old ones. This allows us to detect hits even with unsupported servers, which in turn means we benefit from all the new hit behavior also here.