<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration/test-method-rred, branch 1.9.4</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.9.4</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.9.4'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-07-27T13:52:22Z</updated>
<entry>
<title>rred: truncate result file before writing to it</title>
<updated>2016-07-27T13:52:22Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-27T13:52:22Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0e071dfe205ad21d8b929b4bb8164b008dc7c474'/>
<id>urn:sha1:0e071dfe205ad21d8b929b4bb8164b008dc7c474</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>tests: support spaces in path and TMPDIR</title>
<updated>2015-12-19T22:04:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-12-15T16:20:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2'/>
<id>urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>add more parsing error checking for rred</title>
<updated>2015-06-09T10:57:36Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-06-07T00:17:15Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6d3e5bd8e08564c5eb12ecd869de5bd71e25f59d'/>
<id>urn:sha1:6d3e5bd8e08564c5eb12ecd869de5bd71e25f59d</id>
<content type='text'>
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.
</content>
</entry>
</feed>
