summaryrefslogtreecommitdiff
path: root/test/integration/skip-bug-601016-description-translation
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2016-07-27 15:52:22 +0200
committerJulian Andres Klode <jak@debian.org>2016-08-31 14:16:10 +0200
commit6a6bcc4b3365a4455539271f87be1fa55ea237f1 (patch)
tree3045a95bba5afb085bb3d68a0dfae40404fc4cbb /test/integration/skip-bug-601016-description-translation
parenta8c30aa78bf30586ffa47aa9b9a3ff97f763690a (diff)
rred: truncate result file before writing to it
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 (cherry picked from commit 0e071dfe205ad21d8b929b4bb8164b008dc7c474)
Diffstat (limited to 'test/integration/skip-bug-601016-description-translation')
0 files changed, 0 insertions, 0 deletions