Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.5_rc1 2017-08-24T14:56:52Z 2017-08-24T14:56:52Z Julian Andres Klode jak@debian.org 2017-08-24T14:55:15Z urn:sha1:0e4ac8334d02ea256f750ad61689f28ff1ebdf6c As a follow up to the last commit, let's replace APT_CONST with APT_PURE everywhere to clean stuff up. 2017-08-04T12:33:34Z David Kalnischkies david@kalnischkies.de 2017-08-04T10:51:34Z urn:sha1:e250a8d8d8ef2f8f8c5e2041f7645c49fba7aa36 APT clients always noticed if a method isn't supported and nowadays generate a message of the form: E: The method driver …/foobar could not be found. N: Is the package apt-transport-foobar installed? This only worked if a single source was using such an unavailable method through as we were registering the failed config the first round and the second would try to send requests to the not started method, which wouldn't work and hang instead (+ hiding the error messages as they would be shown only at the end of the execution). Closes: 870675 2017-07-26T17:09:04Z David Kalnischkies david@kalnischkies.de 2017-07-07T20:21:44Z urn:sha1:881ec045b6660e2fe0c6953720260e380ceeeb99 Opening the file before we drop privileges in the methods allows us to avoid chowning in the acquire main process which can apply to the wrong file (imagine Binary scoped settings) and surprises users as their permission setup is overridden. There are no security benefits as the file is open, so an evil method could as before read the contents of the file, but it isn't worse than before and we avoid permission problems in this setup. 2017-07-26T17:07:56Z David Kalnischkies david@kalnischkies.de 2017-07-24T11:04:58Z urn:sha1:85f4a655cdc4d16c1b95de6fad7f3cd955265e46 Weak hashes like filesize can be used by methods for basic checks and early refusals even if we can't use them for hard security proposes. Normal apt operations are not affected by this as they fail if no strong hash is available, but if apt is forced to work with weak-only files or e.g. in apt-helper context it can have benefits as weak is better than no hash for the methods. 2017-07-12T11:57:51Z Julian Andres Klode jak@debian.org 2017-07-12T11:40:41Z urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3 This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh. 2017-06-28T17:18:47Z David Kalnischkies david@kalnischkies.de 2017-05-28T14:55:45Z urn:sha1:ca8da1bf83ecc90ba882520b79c1cda03ee7485d Having messages being printed on the error stack and confirm them by commandline flags is an okayish first step, but some frontends will probably want to have a more interactive feeling here with a proper question the user can just press yes/no for as for some frontends a commandline flag makes no sense… 2017-06-26T21:31:15Z David Kalnischkies david@kalnischkies.de 2017-03-19T11:59:44Z urn:sha1:24fbb6adb071c39e24f9b0a89aadc7d5673a8775 POSIX.1-2008 gives us a range of *at calls to deal with files including the unlinkat so we can remove a file from a directory based on a path to the file relative to the directory. (In our case here the path we have is just the filename) We avoid changing directories in this way which e.g. fails if the directory we started in no longer exists or is otherwise inaccessible. Closes: 860738 2017-01-28T13:06:29Z Julian Andres Klode jak@debian.org 2017-01-25T02:38:59Z urn:sha1:7b78e8bef1fc9de22d826db1db9df25f97d3710c Since the introduction of by-hash, two differently named files might have the same real URL. In our case, the files icons-64x64.tar.gz and icons-128x128.tar.gz of empty tarballs. APT would try to merge them and end with weird errors because it completed the first download and enters the second stage for decompressing and verifying. After that it would queue a new item to copy the original file to the location, but that copy item would be in the wrong stage, causing it to use the hashes for the decompressed item. Closes: #838441 2017-01-19T02:57:45Z David Kalnischkies david@kalnischkies.de 2017-01-19T02:57:45Z urn:sha1:7ca83492e802967f183babf06ab541b1b51f1703 If apt renames a file to .FAILED it leaves its namespace and is never touched again – expect since 1.1~exp4 in which "apt clean" will remove those files. The usefulness of these files rapidly degrades if you don't keep the update log itself (together with debug output in the best case) through and on 99% of all system they will be kept around forever just to collect dust over time and eat up space. With this commit an update call will remove all FAILED files of previous runs, so that the FAILED files you have on disk are always only the ones related to the last apt run stopping apt from hoarding files. Closes: 846476 2016-12-16T12:50:00Z David Kalnischkies david@kalnischkies.de 2016-11-25T14:15:01Z urn:sha1:78db35195eddcd156130fff9ea3e895b30cbf9c3 Note: This is a warning about disabling a security feature. It is supposed to be scary as we are disabling a security feature and we can't just be silent about it! Downloads really shouldn't happen any longer as root to decrease the attack surface – but if a warning causes that much uproar, consider what an error would do… The old WARNING message: | W: Can't drop privileges for downloading as file 'foobar' couldn't be | accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) is frequently (incorrectly) considered to be an error message indicating that the download didn't happen which isn't the case, it was performed, but without all the security features enabled we could have used if run from some other place… The word "unsandboxed" is chosen as the term 'sandbox(ed)' is a common encounter in feature lists/changelogs and more people are hopefully able to make the connection to 'security' than it is the case for 'privilege dropping' which is more correct, but far less known. Closes: #813786 LP: #1522675