Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta4 2016-12-31T02:50:06Z 2016-12-31T02:50:06Z David Kalnischkies david@kalnischkies.de 2016-12-31T02:50:06Z urn:sha1:9544398fce600fb62762c05a8a84231fd1a365b4 On Travis and co the default gpg implementation is gpg1 which for some reason fails if a secret key which was already imported is imported again. We would prefer it to be a NOP like gpg2 handles it so we crudely check the error message. apt-key usually doesn't deal with secret keys – it only learned to do it for manual testing and the integration framework usage, so no public interface is effected. Triggered-By: 4ce2f35248123ff2366c8c365ad6a94945578d66 Gbp-Dch: Ignore 2016-12-21T18:36:10Z David Kalnischkies david@kalnischkies.de 2016-12-18T16:42:17Z urn:sha1:4ce2f35248123ff2366c8c365ad6a94945578d66 Importing a new secret key into gpg(2) can be increadibly slow which prolongs the test runs significantly – by caching the homedir we gain a significant speedbonus as reimporting already present keys seems like a far less costly operation. Git-Dch: Ignore 2016-11-24T23:15:12Z David Kalnischkies david@kalnischkies.de 2016-11-13T19:52:18Z urn:sha1:2906182db398419a9c59a928b7ae73cf7c7aa307 Having binary files in /etc is kinda annoying – not that the armored files are much better – but it is hard to keep tabs on which format the file has ("simple" or "keybox") and different gnupg versions have different default binary formats which can be confusing for users to work with (beside that it is binary). Adding support for this now will enable us in some distant future to move to armored later on, much like we added trusted.gpg.d years before the world picked it up. 2016-11-23T23:21:35Z David Kalnischkies david@kalnischkies.de 2016-11-12T22:22:33Z urn:sha1:8e438ede2f179f2f66268308c24d62952ac06fa4 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 2016-08-26T22:31:03Z Julian Andres Klode jak@debian.org 2016-08-26T22:31:03Z urn:sha1:6a68315e938eb2611806658828ecea86805822e7 2016-08-26T20:17:54Z Julian Andres Klode jak@debian.org 2016-08-23T19:01:06Z urn:sha1:dd7758b9245275a31fde70218db9a531c5859c26 On FreeBSD, readlink -f requires the last component to exist. 2016-08-26T13:49:10Z Julian Andres Klode jak@debian.org 2016-08-23T11:15:15Z urn:sha1:24a59c62efafbdb8387b2d3c5616b04b9fd21306 Several modules use std::array without including the array header. Bad modules. Some modules use STDOUT_FILENO and friends, or close() without including unistd.h, where they are defined. One module also uses WIFEXITED() without including sys/wait.h. Finally, environ is not specified to be defined in unistd.h. We are required to define it ourselves according to POSIX, so let's do that. 2016-08-25T13:22:28Z David Kalnischkies david@kalnischkies.de 2016-08-25T13:22:28Z urn:sha1:29c590951f812d9e9c4f17706e34f2c3315fb1f6 In 105503b4b470c124bc0c271bd8a50e25ecbe9133 we got a warning implemented for unreadable files which greatly improves the behavior of apt update already as everything will work as long as we don't need the keys included in these files. The behavior if they are needed is still strange through as update will fail claiming missing keys and a manual test (which the user will likely perform as root) will be successful. Passing the new warning generated by apt-key through to apt is a bit strange from an interface point of view, but basically duplicating the warning code in multiple places doesn't feel right either. That means we have no translation for the message through as apt-key has no i18n yet. It also means that if the user has a bunch of sources each of them will generate a warning for each unreadable file which could result in quite a few duplicated warnings, but "too many" is better than none. Closes: 834973 2016-08-25T10:42:36Z David Kalnischkies david@kalnischkies.de 2016-08-25T10:42:36Z urn:sha1:105503b4b470c124bc0c271bd8a50e25ecbe9133 apt-key has inconsistent behaviour if it can't read a keyring file: Commands like 'list' skipped silently over such keyrings while 'verify' failed hard resulting in apt to report cconfusing gpg errors (#834973). As a first step we teach apt-key to be more consistent here skipping in all commands over unreadable keyrings, but issuing a warning in the process, which is as usual for apt commands displayed at the end of the run. 2016-08-17T12:12:24Z David Kalnischkies david@kalnischkies.de 2016-08-17T06:10:29Z urn:sha1:e289907f5e7241034cb0d37055dc2cba4e3a19af Fingerprints tend to be displayed in space-separated octet pairs so be nice and allow delete to remove a key based on such a string rather than requiring that the user is deleting all the spaces manually.