Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_pre3 2016-07-27T20:42:24Z 2016-07-27T20:42:24Z David Kalnischkies david@kalnischkies.de 2016-07-27T20:21:58Z urn:sha1:196d590a99e309764e07c9dc23ea98897eebf53a Reported-By: cppcheck Gbp-Dch: Ignore 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 2016-07-22T14:05:10Z David Kalnischkies david@kalnischkies.de 2016-07-21T13:54:22Z urn:sha1:84255101ee38693aea2fd456cf0da174434afa01 Hardcoding /var/crash means we can't test it properly and it isn't really our style. 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-03T21:09:04Z urn:sha1:27f38567fe327ecaf7fb361c3cca6ee29e6300c9 Gbp-Dch: Ignore 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-22T11:04:47Z urn:sha1:01047752b34486607665db99afffa595cb2d43ce If the sources file we want to edit doesn't exist yet GetLock will create it with 640, which for a generic lockfile might be okay, but as this is a sources file more relaxed permissions are in order – and actually required as it wont be readable for unprivileged users causing warnings/errors in apt calls. Reported-By: J. Theede (musca) on IRC 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-20T16:38:38Z urn:sha1:70bef3257a4dc7751444db8dadedd207bd24ab35 The tests changes the sources.list and the modification time of this file is considered while figuring out if the cache can be good. Usually this isn't an issue, but in that case we have the cache generation produce warnings which appear twice in this case. Gbp-Dch: Ignore 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-20T16:09:46Z urn:sha1:e5c3f3ccd98e926b91693d961db4d338fd144301 The existing cleanup was happening only for packages which had a status change (install -> uninstalled) which is the most frequent but no the only case – you can e.g. set autobits explicitly with apt-mark. This would leave stanzas in the states file declaring a package to be manually installed – which is the default value for a package not listed at all, so we can just as well drop it from the file. 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-20T12:56:06Z urn:sha1:c1e202d225eea6838acd65ea81266996ee6bb9a2 Otherwise calls like "apt -q install" end up calling "aptautotest_apt_q" instead of "aptautotest_apt_install" Gbp-Dch: Ignore 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-08T13:59:23Z urn:sha1:92296fe4b0862a04ea3d965b4cd2d4a420e3be9f We support installing ./foo.deb (and ./foo.dsc for source) for a while now, but it can be a bit clunky to work with those directly if you e.g. build packages locally in a 'central' build-area. The changes files also include hashsums and can be signed, so this can also be considered an enhancement in terms of security as a user "just" has to verify the signature on the changes file then rather than checking all deb files individually in these manual installation procedures. 2016-07-22T14:04:36Z David Kalnischkies david@kalnischkies.de 2016-07-20T07:03:09Z urn:sha1:e8e5d464623f1c2e1ef96b14e622728bbf4b89af If a user explicitly requests the download of arch:all apt shouldn't get in the way and perform its detection dance if arch:all packages are (also) in arch:any files or not. This e.g. allows setting arch=all on a source with such a field (or one which doesn't support all at all, but has the arch:all files like Debian itself ATM) to get only the arch:all packages from there instead of behaving like a no-op. Reported-By: Helmut Grohne on IRC