Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-06-15T21:35:55Z 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-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-07T22:06:41Z urn:sha1:4f51fd8636592a96aecf17c8bf4cfdb3ea2207cc At the moment we only have hashes for the uncompressed pdiff files, but via the new '$HASH-Download' field in the .diff/Index hashes can be provided for the .gz compressed pdiff file, which apt will pick up now and use to verify the download. Now, we "just" need a buy in from the creators of repositories… 2015-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-07T00:17:15Z urn:sha1:6d3e5bd8e08564c5eb12ecd869de5bd71e25f59d The rred parser is very accepting regarding 'invalid' files. Given that we can't trust the input it might be a bit too relaxed. In any case, checking for more errors can't hurt given that we support only a very specific subset of ed commands. 2015-06-09T10:57:36Z David Kalnischkies david@kalnischkies.de 2015-06-06T17:16:45Z urn:sha1:3679515479136179e0d95325a6559fcc6d0af7f8 rred is responsible for unpacking and reading the patch files in one go, but we currently only have hashes for the uncompressed patch files, so the handler read the entire patch file before dispatching it to the worker which would read it again – both with an implicit uncompress. Worse, while the workers operate in parallel the handler is the central orchestration unit, so having it busy with work means the workers do (potentially) nothing. This means rred is working with 'untrusted' data, which is bad. Yet, having the unpack in the handler meant that the untrusted uncompress was done as root which isn't better either. Now, we have it at least contained in a binary which we can harden a bit better. In the long run, we want hashes for the compressed patch files through to be safe. 2015-05-11T15:22:32Z David Kalnischkies david@kalnischkies.de 2015-04-27T08:59:27Z urn:sha1:146f7715a9f36d246b461255b3c683b479296915 Especially pdiff-enhanced downloads have the tendency to fail for various reasons from which we can recover and even a successful download used to leave the old unpatched index in partial/. By adding a new method responsible for making the transaction of an individual file happen we can at specialisations especially for abort cases to deal with the cleanup. This also helps in keeping the compressed indexes around if another index failed instead of keeping the decompressed files, which we wouldn't pick up in the next call. 2015-04-18T23:13:10Z David Kalnischkies david@kalnischkies.de 2015-04-12T15:08:46Z urn:sha1:ba6b79bd0090077724fa1272ea4d3a31706fcd5a If we get a IMSHit for the Transaction-Manager (= the InRelease file or as its still supported fallback Release + Release.gpg combo) we can assume that every file we would queue based on this manager, but already have locally is current and hence would get an IMSHit, too. We therefore save us and the server the trouble and skip the queuing in this case. Beside speeding up repetative executions of 'apt-get update' this way we also avoid hitting hashsum errors if the indexes are in fact already updated, but the Release file isn't yet as it is the case on well behaving mirrors as Release files is updated last. The implementation is a bit harder than the theory makes it sound as we still have to keep reverifying the Release files (e.g. to detect now expired once to avoid an attacker being able to silently stale us) and have to handle cases in which the Release file hits, but some indexes aren't present (e.g. user added a new foreign architecture). 2015-03-16T17:01:54Z David Kalnischkies david@kalnischkies.de 2015-03-09T23:59:44Z urn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore 2014-11-08T13:26:00Z David Kalnischkies david@kalnischkies.de 2014-11-05T17:04:29Z urn:sha1:c355ea30383486e74635cd0248d3b53ed9759c39 One word: "doh!" Commit f6d4ab9ad8a2cfe52737ab620dd252cf8ceec43d disabled the check to prevent apt from downloading bigger patches than the index it tries to patch. Happens rarly of course, but still. Detected by scan-build complaining about a dead assignment. To make up for the mistake a test is included as well. 2014-10-07T14:38:03Z Michael Vogt mvo@ubuntu.com 2014-10-07T14:38:03Z urn:sha1:4d0818cc39f7c0d44ecdfcdf9701058f81caa492 Conflicts: apt-pkg/acquire-item.cc 2014-09-29T23:53:47Z David Kalnischkies david@kalnischkies.de 2014-09-29T20:45:52Z urn:sha1:f6d4ab9ad8a2cfe52737ab620dd252cf8ceec43d The fileformat of a pdiff index stores currently only SHA1 hashes. With this change, we look for all other hashes we support as well and take what we get, so that we can work after the release of jessie to get right of SHA1 if we want to. Note that the completely patched file is and was checked against the hashes collected from the Release file, so this transition isn't mission critical.