apt/apt-pkg/contrib, branch 1.4_rc1

avoid malloc if option whitelist is disabled (default)

2017-01-27T20:06:09Z

Config options are checked in various paths, so making "useless" memory allocations wastes time and can also cause problems like #852757. The unneeded malloc was added in ae73a2944a89e0d2406a2aab4a4c082e1e9da3f9. (We have no explicit malloc here – its std:string doing this internally)

fix various typos reported by spellintian

2017-01-19T14:59:38Z

Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian

fix various typos reported by codespell

2017-01-19T14:59:38Z

Nothing in user visible strings. Gbp-Dch: Ignore Reported-By: codespell

strutl: Provide an APT::String::Join() function

2017-01-16T23:07:09Z

Thanks: James Clarke for the implementation Gbp-Dch: ignore

allow warning generation for non-whitelisted options

2016-12-31T17:24:12Z

The idea is simple: Each¹ Find*( call starts with a call check if the given option (with the requested type) exists in the whitelist. The whitelist is specified via our configure-index file so that we have a better chance at keeping it current. the whitelist is loaded via a special (undocumented for now) configuration stanza and if none is loaded the empty whitelist will make it so that no warnings are shown. Much needs to be done still, but that is as good a time as any to take a snapshot of the current state and release it into the wild given that it found some bugs already and has no practical effect on users. ¹ not all in this iteration, but many

warn if clearsigned file has ignored content parts

2016-12-31T01:29:19Z

Clearsigned files like InRelease, .dsc, .changes and co can potentially include unsigned or additional messages blocks ignored by gpg in verification, but a potential source of trouble in our own parsing attempts – and an unneeded risk as the usecases for the clearsigned files we deal with do not reasonably include unsigned parts (like emails or some such). This commit changes the silent ignoring to warnings for now to get an impression on how widespread unintended unsigned parts are, but eventually we want to turn these into hard errors.

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

Compare size before data when ordering cache bucket entries

2016-11-22T21:58:19Z

This has the effect of significantly reducing actual string comparisons, and should improve the performance of FindGrp a bit, although it's hardly measureable (callgrind says it uses 10% instructions less now).