Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1_exp15 2015-11-04T17:42:27Z 2015-11-04T17:42:27Z David Kalnischkies david@kalnischkies.de 2015-10-28T13:38:49Z urn:sha1:1dd20368486820efb6ef4476ad739e967174bec4 Based on a discussion with Niels Thykier who asked for Contents-all this implements apt trying for all architecture dependent files to get a file for the architecture all, which is treated internally now as an official architecture which is always around (like native). This way arch:all data can be shared instead of duplicated for each architecture requiring the user to download the same information again and again. There is one problem however: In Debian there is already a binary-all/ Packages file, but the binary-any files still include arch:all packages, so that downloading this file now would be a waste of time, bandwidth and diskspace. We therefore need a way to decide if it makes sense to download the all file for Packages in Debian or not. The obvious answer would be a special flag in the Release file indicating this, which would need to default to 'no' and every reasonable repository would override it to 'yes' in a few years time, but the flag would be there "forever". Looking closer at a Release file we see the field "Architectures", which doesn't include 'all' at the moment. With the idea outlined above that 'all' is a "proper" architecture now, we interpret this field as being authoritative in declaring which architectures are supported by this repository. If it says 'all', apt will try to get all, if not it will be skipped. This gives us another interesting feature: If I configure a source to download armel and mips, but it declares it supports only armel apt will now print a notice saying as much. Previously this was a very cryptic failure. If on the other hand the repository supports mips, too, but for some reason doesn't ship mips packages at the moment, this 'missing' file is silently ignored (= that is the same as the repository including an empty file). The Architectures field isn't mandatory through, so if it isn't there, we assume that every architecture is supported by this repository, which skips the arch:all if not listed in the release file. 2015-11-04T17:04:02Z David Kalnischkies david@kalnischkies.de 2015-10-20T16:31:10Z urn:sha1:995a4bf6d770a5cc824c38388909f23fcca558c3 apt is an interactive command and the reasons we haven't this option set for everything is mostly in keeping compatibility for a little while longer to allow scripts to be changed if need be. 2015-11-04T17:04:01Z David Kalnischkies david@kalnischkies.de 2015-10-15T07:35:52Z urn:sha1:002b1bc46b18e9d309d337ddb15a6ccdfb6c9dde The manpage is also slightly updated to work better as a central hub to push people from all angles into the right directions without writting a book disguised as an error message. 2015-11-04T17:04:01Z David Kalnischkies david@kalnischkies.de 2015-10-13T09:37:39Z urn:sha1:f18f2338a17d3037ac0d6f81a7f1a37df6eaca01 Insecure (aka unsigned) repositories are bad, period. We want to get right of them finally and as a first step we are printing scary warnings. This is already done, this commit just changes the messages to be more consistent and prevents them from being displayed if authenticity is guaranteed some other way (as indicated with trusted=yes). The idea is to first print the pure fact like "repository isn't signed" as a warning (and later as an error), while giving an explaination in a immediately following notice (which is displayed only in quiet level 0: so in interactive use, not in scripts and alike). Closes: 796549 2015-09-15T08:16:09Z David Kalnischkies david@kalnischkies.de 2015-09-14T22:33:12Z urn:sha1:6c0765c096ffb4df14169236c865bbb2b10974ae This allows running tests in parallel. Git-Dch: Ignore 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-10T19:10:17Z urn:sha1:90b56f542e0ae722c843265f4e6250cc0a096f5d The tests usually run on amd64 boxes, but once in a while I run it on a (slow) armel box as well, which has its fair share of problems with some tests, but at least the low hanging fruits can be dealt with: Do not assume that amd64 is the native dpkg architecture – instead use whatever dpkg thinks is native as architecture for the test. Git-Dch: Ignore 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-10T17:00:51Z urn:sha1:95278287f4e1eeaf5d96749d6fc9bfc53fb400d0 Our error reporting is historically grown into some kind of mess. A while ago I implemented stacking for the global error which is used in this commit now to wrap calls to functions which do not report (all) errors via return, so that only failures in those calls cause a failure to propergate down the chain rather than failing if anything (potentially totally unrelated) has failed at some point in the past. This way we can avoid stopping the entire acquire process just because a single source produced an error for example. It also means that after the acquire process the cache is generated – even if the acquire process had failures – as we still have the old good data around we can and should generate a cache for (again). There are probably more instances of this hiding, but all these looked like the easiest to work with and fix with reasonable (aka net-positive) effects. 2015-06-15T21:35:55Z David Kalnischkies david@kalnischkies.de 2015-06-15T21:06:56Z urn:sha1:9d2a8a7388cf3b0bbbe92f6b0b30a533e1167f40 It shouldn't be too common, but sometimes people have multiple mirrors in the sources or otherwise repositories with the same content. Now that we gracefully can handle multiple requests to the same URI, we can also fold multiple requests with the same expected hashes into one. Note that this isn't trying to find oppertunities for merging, but just merges if it happens to encounter the oppertunity for it. This is most obvious in the new testcase actually as it needs to delay the action to give the acquire system enough time to figure out that they can be merged. 2015-06-15T21:35:55Z David Kalnischkies david@kalnischkies.de 2015-06-15T14:41:43Z urn:sha1:1eb1836f4b5397497bd34f0cf516e6e4e73117bf Again, consistency is the main sellingpoint here, but this way it is now also easier to explain that some files move through different stages and lines are printed for them hence multiple times: That is a bit hard to believe if the number is changing all the time, but now that it keeps consistent. 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.