apt/apt-pkg/contrib/gpgv.cc, branch 1.4_beta2

gpgv: Flush the files before checking for errors

2016-12-08T14:19:30Z

This is a follow up to the previous issue where we did not check if getline() returned -1 due to an end of file or due to an error like memory allocation, treating both as end of file. Here we ensure that we also handle buffered writes correctly by flushing the files before checking for any errors in our error stack. Buffered writes themselves were introduced in 1.1.9, but the function was never called with a buffered file from inside apt until commit 46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c which was first released with apt 1.2.10. The function is public, though, so fixing this is a good idea anyway. Affected: >= 1.1.9

SECURITY UPDATE: gpgv: Check for errors when splitting files (CVE-2016-1252)

2016-12-08T14:19:21Z

This fixes a security issue where signatures of the InRelease files could be circumvented in a man-in-the-middle attack, giving attackers the ability to serve any packages they want to a system, in turn giving them root access. It turns out that getline() may not only return EINVAL as stated in the documentation - it might also return in case of an error when allocating memory. This fix not only adds a check that reading worked correctly, it also implicitly checks that all writes worked by reporting any other error that occurred inside the loop and was logged by apt. Affected: >= 0.9.8 Reported-By: Jann Horn Thanks: Jann Horn, Google Project Zero for reporting the issue LP: #1647467

report apt-key errors via status-fd messages

2016-11-23T23:21:35Z

We report warnings from apt-key this way already since 29c590951f812d9e9c4f17706e34f2c3315fb1f6, so reporting errors seems like a good addition. Most of those errors aren't really from apt-key through, but from the code setting up and actually calling it which used to just print to stderr which might or might not intermix them with (other) progress lines in update calls. Having them as proper error messages in the system means that the errors are actually collected later on for the list instead of ending up with our relatively generic but in those cases bogus hint regarding "is gpgv installed?". The effective difference is minimal as the errors apply mostly to systems which have far worse problems than a not as nice looking error message, which makes this pretty hard to test – but at least now the hint that your system is broken can be read in proper order (= there aren't many valid cases in which the permissions of /tmp are messed up…). LP: #1522988

Make directory paths configurable

2016-08-26T20:17:54Z

This allows other vendors to use different paths, or to build your own APT in /opt for testing. Note that this uses + 1 in some places, as the paths we receive are absolute, but we need to strip of the initial /.

ExecGPGV: Pass current config state to apt-key via temp file

2016-08-03T17:00:01Z

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

ExecGPGV: Rework file removal on exit()

2016-08-03T16:44:27Z

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

Previously, when data could be created and sig not, we would unlink sig, not data (and vice versa).

don't use FindFile for external Dir::Bin commands

2016-06-14T12:32:14Z

We usually use absolute paths to specific the location of dpkg, apt-key and the like, but there is nothing wrong with using just the command name and instead let exec(3) make the lookup in PATH. We had a wild mixture before, so opting for the more accepting option out of the two seems about right especially as it makes no difference in the default case as apt uses absolute paths.

use buffered writing for InRelease splitting

2016-04-03T12:44:47Z

Hardly noticeable, but given that we have the option to easily enable it, lets enable it as every newline in the message is written individually by the code.