fix "(style) Statements following return, break, continue, goto or throw
will never be executed." from cppcheck. The fd was closed only after a
return, so invert the order of lines and be happy
* apt-pkg/acquire-item.cc:
- remove 'old' InRelease file if we can't get a new one before
proceeding with Release.gpg to avoid the false impression of a still
trusted repository by a (still present) old InRelease file.
Thanks to Simon Ruderich for reporting this issue! (CVE-2012-0214)
Effected are all versions >= 0.8.11
Possible attack summary:
- Attacker needs to find a user which has run at least one successful
'apt-get update' against an archive providing InRelease files.
- Create a Packages file with his preferred content.
- Attacker then prevents the download of InRelease, Release and
Release.gpg (alternatively he creates a valid Release file and sends
this, the other two files need to be missing either way).
- User updates against this, getting the modified Packages file without
any indication of being unsigned (beside the "Ign InRelease" and
"Ign Release.gpg" in the output of 'apt-get update').
=> deb files from this source are considered 'trusted' (and therefore the
user isn't asked for an additional confirmation before install)
* cmdline/apt-get.cc:
- if a package can't be removed as it is not installed, suggest to
the user an (installed) multiarch silbing with 'Did you mean?'
* apt-pkg/acquire-item.cc:
- drop support for i18n/Index file (introduced in 0.8.11) and use
the Release file instead to get the Translations (Closes: #649314)
* ftparchive/writer.cc:
- add 'Translation-*' to the default patterns
i18n/Index was never used outside debian - and even here it isn't used
consistently as only 'main' has such a file. As the Release file now
includes the Translation-* files we therefore drop support for i18n/Index.
A version supporting it was never part of a debian release and still
supporting it would mean that we get 99% of the time a 404 as response
to the request anyway and confuse archive maintainers who want to
provide all files APT tries to acquire.
Fix the testcases to work with and configure dpkg correctly in a
multi-arch environment
It's not a complete and the "fixed" test is fixed more like a hack
as we have communication problems with dpkg if dpkg and APT disagree
on the interpretation of the native architecture, see also:
http://lists.debian.org/debian-dpkg/2012/02/msg00051.html
* methods/http{s,}.cc:
- if a file without an extension is requested send an 'Accept: text/*'
header to avoid that the server chooses unsupported compressed files
in a content-negotation attempt (Closes: #657560)
Colin Watson [Sun, 29 Jan 2012 13:47:34 +0000 (14:47 +0100)]
* apt-pkg/algorithms.cc:
- use a signed int instead of short for score calculation as upgrades
become so big now that it can overflow (Closes: #657732, LP: #917173)
Colin Watson [Sun, 29 Jan 2012 12:53:25 +0000 (13:53 +0100)]
* apt-pkg/algorithms.cc:
- don't break out of the main-resolver loop for Breaks to deal with all
of them in a single iteration (Closes: #657695, LP: #922485)
Pino Toscano [Fri, 20 Jan 2012 00:34:31 +0000 (01:34 +0100)]
* test/libapt/globalerror_test.cc:
- errno 0 has a different strerror on hurd, so generate the expected
message dynamically instead of hardcoding 'Success' (Closes: #656530)
* methods/https.cc:
- use curls list append instead of appending Range and If-Range by hand
which generates malformed requests, thanks Mel Collins for the hint!
(Closes: #646381)
* apt-pkg/cacheiterators.h:
- return the correct version arch for all+foreign, too
The flag is interpreted at a few other places in different styles so
this commit ensures that the flag check is consistent everywhere
(checking for Same in flag style is a bit too much as it isn't used
in combination with others anyway, but who knows and just for
consistency)
Michael Vogt [Thu, 19 Jan 2012 12:46:09 +0000 (13:46 +0100)]
* apt-pkg/deb/dpkgpm.cc:
- redirect out/input of dpkg --assert-multi-arch to /dev/null
- if multi-arch is detected ensure that pkg:all is reported as pkg:all
Michael Vogt [Wed, 18 Jan 2012 09:27:15 +0000 (10:27 +0100)]
* apt-pkg/contrib/fileutl.h:
- store the offset in the internal fd before calculate size of
the zlib-handled file to jump back to this place again
* apt-pkg/contrib/fileutl.h:
* apt-pkg/contrib/fileutl.h:
- store the offset in the internal fd before calculate size of
the zlib-handled file to jump back to this place again
It jumped back to the position of the content - which is wrong as
the internal fd is compressed and even reseting to the beginning of
the file doesn't work as zlib uses an internal buffer, so while we
might haven't read anything yet zlib might have done so already…