Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.5_alpha1 2017-01-19T03:14:08Z 2017-01-19T03:14:08Z David Kalnischkies david@kalnischkies.de 2017-01-19T03:14:08Z urn:sha1:2984d7aec37e09b473c7b99f43d20622c25dc99d rred can fail for a plentory of reasons, but its failure is usually recoverable (Ign lines) so it shouldn't leak unrequested debug messages to an observing user. Closes: #850759 2016-09-01T14:13:14Z David Kalnischkies david@kalnischkies.de 2016-08-31T08:11:07Z urn:sha1:644478e8db56f305601c3628a74e53de048b28c8 memcpy is marked as nonnull for its input, but ignores the input anyhow if the declared length is zero. Our SHA2 implementations do this as well, it was "just" MD5 and SHA1 missing, so we add the length check here as well as along the callstack as it is really pointless to do all these method calls for "nothing". Reported-By: gcc -fsanitize=undefined 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-07-31T16:05:56Z urn:sha1:30060442025824c491f58887ca7369f3c572fa57 The https method implemented for a long while now a hardcoded fallback to the same options in http, which, while it works, is rather inflexible if we want to allow the methods to use another name to change their behavior slightly, like apt-transport-tor does to https – most of the diff being s#https#tor#g which then fails to do the full circle fallthrough tor -> https -> http for https sources. With this config infrastructure this could be implemented now. 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 2016-07-25T22:01:50Z David Kalnischkies david@kalnischkies.de 2016-07-25T22:01:50Z urn:sha1:6e71ec6fcdcaa926c98fa58cd4af38e42556df15 We read the entire input file we want to patch anyhow, so we can also calculate the hash for that file and compare it with what he had expected it to be. Note that this isn't really a security improvement as a) the file we patch is trusted & b) if the input is incorrect, the result will hardly be matching, so this is just for failing slightly earlier with a more relevant error message (althrough, in terms of rred its ignored and complete download attempt instead). 2016-05-28T16:12:02Z David Kalnischkies david@kalnischkies.de 2016-05-28T11:22:38Z urn:sha1:8b79c94af7f7cf2e5e5342294bc6e5a908cacabf We use a wild mixture of C and C++ ways of generating output, so having a consistent world-view in both styles sounds like a good idea and should help in preventing regressions. 2016-02-04T16:56:27Z Julian Andres Klode jak@debian.org 2016-02-04T16:56:27Z urn:sha1:610e13842a3718128c03454c5dfcbde49d323281 We basically ignored errors from writing and flushing, let's not do that. 2016-01-26T14:32:15Z David Kalnischkies david@kalnischkies.de 2016-01-25T21:13:52Z urn:sha1:2651f1c071927b7fc440ec7a638ecad7ccf04a2e Reported-By: cppcheck Git-Dch: Ignore 2016-01-08T14:40:01Z David Kalnischkies david@kalnischkies.de 2016-01-05T23:05:24Z urn:sha1:4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e There is no reason to enforce that the file we start the bootstrap with is compressed with a compressor which is available online. This allows us to change the on-disk format as well as deals with repositories adding/removing support for a specific compressor. 2016-01-07T16:32:39Z Julian Andres Klode jak@debian.org 2016-01-07T16:09:30Z urn:sha1:4fcff7ed46aec6c0147abe855c13dd537277273e Remove the SingleInstance flag so we can use the new randomized queue feature to run parallel.