Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=master 2021-03-06T14:02:26Z 2021-03-06T14:02:26Z David Kalnischkies david@kalnischkies.de 2021-03-06T14:02:26Z urn:sha1:9bd27033c4786fa89cebc9d090ad2c6e8f47b598 There isn't a lot of sense in working on empty patches as they change nothing (quite literally), but they can be the result of merging multiple patches and so to not require our users to specifically detect and remove them, we can be nice and just ignore them instead of erroring out. 2020-12-02T15:41:40Z Julian Andres Klode jak@debian.org 2020-12-02T15:41:40Z urn:sha1:eefadade6e886d9423c5d3145858891047c46abc Fixes lookup in as-installed testing Gbp-Dch: ignore 2020-11-07T21:52:20Z David Kalnischkies david@kalnischkies.de 2020-11-07T21:52:20Z urn:sha1:e5bb443cf58cec23503ad0deeeb06a080053da8a 2020-11-07T20:48:21Z David Kalnischkies david@kalnischkies.de 2020-11-07T20:39:00Z urn:sha1:418f9272606857e312f485778a1ef1b263236463 The acquire system mode does this for a long time already and as it is easy to implement and handy for manual testing as well we can support it in the other modes, too. 2020-11-07T20:48:21Z David Kalnischkies david@kalnischkies.de 2020-11-07T20:23:57Z urn:sha1:9e1398b164f55238990907f63dfdef60588d9b24 Merging patches is a bit of non-trivial code we have for client-side work, but as we support also server-side merging we can export this functionality so that server software can reuse it. Note that this just cleans up and makes rred behave a bit more like all our other binaries by supporting setting configuration at runtime and supporting --help and --version. If you can make due without this, the now advertised functionality is provided already in earlier versions. 2016-07-27T13:52:22Z David Kalnischkies david@kalnischkies.de 2016-07-27T13:52:22Z urn:sha1:0e071dfe205ad21d8b929b4bb8164b008dc7c474 If another file in the transaction fails and hence dooms the transaction we can end in a situation in which a -patched file (= rred writes the result of the patching to it) remains in the partial/ directory. The next apt call will perform the rred patching again and write its result again to the -patched file, but instead of starting with an empty file as intended it will override the content previously in the file which has the same result if the new content happens to be longer than the old content, but if it isn't parts of the old content remain in the file which will pass verification as the new content written to it matches the hashes and if the entire transaction passes the file will be moved the lists/ directory where it might or might not trigger errors depending on if the old content which remained forms a valid file together with the new content. This has no real security implications as no untrusted data is involved: The old content consists of a base file which passed verification and a bunch of patches which all passed multiple verifications as well, so the old content isn't controllable by an attacker and the new one isn't either (as the new content alone passes verification). So the best an attacker can do is letting the user run into the same issue as in the report. Closes: #831762 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-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.