Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.5 2016-01-26T14:32:15Z 2016-01-26T14:32:15Z David Kalnischkies david@kalnischkies.de 2016-01-25T21:13:52Z urn:sha1:2651f1c071927b7fc440ec7a638ecad7ccf04a2e Reported-By: cppcheck Git-Dch: Ignore 2015-11-19T15:46:29Z David Kalnischkies david@kalnischkies.de 2015-11-18T18:31:40Z urn:sha1:514a25cbcd2babb2a9c4485fc7b9a4256b7f6ff3 In 0940230d we started dropping privileges for file (and a bit later for copy, too) with the intend of uniforming this for all methods. The commit message says that the source will likely fail based on the compressors already – and there isn't much secret in the repository content. After all, after apt has run the update everyone can access the content via apt anyway… There are sources through which worked before which are mostly single-deb (and those with the uncompressed files available). The first one being especially surprising for users maybe, so instead of failing, we make it so that apt detects that it can't access a source as _apt and if so doesn't drop (for all sources!) privileges – but we limit this to file/copy, so the uncompress which might be needed will still fail – but that failed before this regression. We display a notice about this, mostly so that if it still fails (e.g. compressed) the user has some idea what is wrong. Closes: 805069 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T17:49:52Z urn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39 Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore 2015-11-04T17:04:01Z David Kalnischkies david@kalnischkies.de 2015-10-12T14:48:59Z urn:sha1:9f301e0f2d828d662bd67da2be9d8f227caadd07 All other reasons from methods/connect.cc were already included. Git-Dch: Ignore 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-11T18:53:07Z urn:sha1:ae732225ec2fa0d7434c9f40a92ced8683752211 Reported-By: gcc Understandable: no Git-Dch: Ignore 2015-09-01T12:19:44Z David Kalnischkies david@kalnischkies.de 2015-09-01T11:58:00Z urn:sha1:63d609985eb7eefa5f2332bfe4fab96f017760a1 We want to declare some hashes as not enough for security, so that a user will need --allow-unauthenticated or similar to get data secured only by those hashes, but we can still us these hashes for integrity checks if we got them. 2015-08-27T09:27:43Z David Kalnischkies david@kalnischkies.de 2015-08-21T22:10:08Z urn:sha1:b6a0018e1c4bb22132e0316a81b7a455c6333cf1 Fetched() was reported for mostly nothing, while we should be calling it for files worked with from non-local sources (e.g. http, but not file or xz). Previously this was called from an acquire item, but got moved to the acquire worker instead to avoid having it (re)implemented in all items, but the checks were faulty. 2015-08-17T12:29:02Z Michael Vogt mvo@debian.org 2015-08-17T12:29:02Z urn:sha1:ac7f8f7916f16905d8eeb0133bc650d89726d0f4 Git-Dch: ignore 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba 2015-08-12T09:55:47Z Luca Bruno lethalman88@gmail.com 2015-08-11T18:08:43Z urn:sha1:94171725b18be91ddcc2530c5fe5f40e78d041c1 Thanks: Andre Felipe Machado for initial patch Closes: 414848