apt/apt-pkg, branch 1.3

apt/apt-pkg, branch 1.3_pre3 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre3 2016-08-03T17:00:01Z ExecGPGV: Pass current config state to apt-key via temp file 2016-08-03T17:00:01Z Julian Andres Klode jak@debian.org 2016-08-03T16:50:37Z urn:sha1:98f884ebec556bafe6f9650e105fc7c60580e730 Create a temporary configuration file with a dump of our configuration and pass that to apt-key. LP: #1607283 ExecGPGV: Fork in all cases 2016-08-03T16:45:51Z Julian Andres Klode jak@debian.org 2016-08-03T16:45:51Z urn:sha1:81ee750f90bb4d21a0441196ce105f6848633616 ExecGPGV: Rework file removal on exit() 2016-08-03T16:44:27Z Julian Andres Klode jak@debian.org 2016-08-03T16:44:27Z urn:sha1:e0a243f33cd411f730af3c93aff38635c9668f9e Create a local exiter object which cleans up files on exit. gpgv: Unlink the correct temp file in error case 2016-08-03T14:40:14Z Julian Andres Klode jak@debian.org 2016-07-28T10:41:27Z urn:sha1:d0d06f44ed60a3888528d834a799bae86c2978d5 Previously, when data could be created and sig not, we would unlink sig, not data (and vice versa). prevent C++ locale number formatting in text APIs (try 2) 2016-07-30T08:14:47Z David Kalnischkies david@kalnischkies.de 2016-07-30T07:57:50Z urn:sha1:7303e11ff28f920a6277c159aa46f80c007350bb Followup of b58e2c7c56b1416a343e81f9f80cb1f02c128e25. Still a regression of sorts of 8b79c94af7f7cf2e5e5342294bc6e5a908cacabf. Closes: 832044 edsp: try to read responses even if writing failed 2016-07-29T20:09:06Z David Kalnischkies david@kalnischkies.de 2016-07-29T19:51:43Z urn:sha1:b60c8a89c281f2bb945d426d2215cbf8f5760738 If a solver/planner exits before apt is done writing we will generate write errors. Solvers like 'dump' can be pretty quick in failing but produce a valid EDSP error report apt should read, parse and display instead of just discarding even through we had write errors. if the FileFd failed already following calls should fail, too 2016-07-29T20:09:04Z David Kalnischkies david@kalnischkies.de 2016-07-29T19:39:20Z urn:sha1:02c38073af51802c02bb104d4450e0e112d641ad There is no point in trying to perform Write/Read on a FileFd which already failed as they aren't going to work as expected, so we should make sure that they fail early on and hard. (error) va_list 'args' was opened but not closed by va_end() 2016-07-27T20:42:24Z David Kalnischkies david@kalnischkies.de 2016-07-27T20:21:58Z urn:sha1:196d590a99e309764e07c9dc23ea98897eebf53a Reported-By: cppcheck Gbp-Dch: Ignore eipp: avoid producing file warnings in simulation 2016-07-27T15:58:51Z David Kalnischkies david@kalnischkies.de 2016-07-27T15:58:51Z urn:sha1:4a97f759cd98f3b2518726b348d1b981e8a8e1d6 Simulations are frequently run by unprivileged users which naturally don't have the permissions to write to the default location for the eipp file. Either way is bad as running in simulation mode doesn't mean we don't want to run the logging (as EIPP runs the same regardless of simulation or 'real' run), but showing the warnings is relatively pointless in the default setup, so, in case we would produce errors and perform a simulation we will discard the warnings and carry on. Running apt with an external planner wouldn't have generated these messages btw. Closes: 832614 rred: truncate result file before writing to it 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