Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3 2016-08-26T20:17:54Z 2016-08-26T20:17:54Z Julian Andres Klode jak@debian.org 2016-08-23T17:41:58Z urn:sha1:8757a0fdeee00ea6a7cc717188a0e129ad8a553c This allows other vendors to use different paths, or to build your own APT in /opt for testing. Note that this uses + 1 in some places, as the paths we receive are absolute, but we need to strip of the initial /. 2016-08-03T17:00:01Z Julian Andres Klode jak@debian.org 2016-08-03T16:50:37Z urn:sha1:98f884ebec556bafe6f9650e105fc7c60580e730 Create a temporary configuration file with a dump of our configuration and pass that to apt-key. LP: #1607283 2016-08-03T16:45:51Z Julian Andres Klode jak@debian.org 2016-08-03T16:45:51Z urn:sha1:81ee750f90bb4d21a0441196ce105f6848633616 2016-08-03T16:44:27Z Julian Andres Klode jak@debian.org 2016-08-03T16:44:27Z urn:sha1:e0a243f33cd411f730af3c93aff38635c9668f9e Create a local exiter object which cleans up files on exit. 2016-08-03T14:40:14Z Julian Andres Klode jak@debian.org 2016-07-28T10:41:27Z urn:sha1:d0d06f44ed60a3888528d834a799bae86c2978d5 Previously, when data could be created and sig not, we would unlink sig, not data (and vice versa). 2016-06-14T12:32:14Z David Kalnischkies david@kalnischkies.de 2016-06-14T12:32:14Z urn:sha1:90f2a7a0f66cfc259883490a5fcf40f7d0696cfe We usually use absolute paths to specific the location of dpkg, apt-key and the like, but there is nothing wrong with using just the command name and instead let exec(3) make the lookup in PATH. We had a wild mixture before, so opting for the more accepting option out of the two seems about right especially as it makes no difference in the default case as apt uses absolute paths. 2016-04-03T12:44:47Z David Kalnischkies david@kalnischkies.de 2016-03-25T11:15:00Z urn:sha1:46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c Hardly noticeable, but given that we have the option to easily enable it, lets enable it as every newline in the message is written individually by the code. 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-24T17:31:22Z urn:sha1:b0d408547734100bf86781615f546487ecf390d9 Limits which key(s) can be used to sign a repository. Not immensely useful from a security perspective all by itself, but if the user has additional measures in place to confine a repository (like pinning) an attacker who gets the key for such a repository is limited to its potential and can't use the key to sign its attacks for an other (maybe less limited) repository… (yes, this is as weak as it sounds, but having the capability might come in handy for implementing other stuff later). 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-18T15:33:15Z urn:sha1:3d8232bf97ce11818fb07813a71136484ea1a44a Various small leaks here and there. Nothing particularily big, but still good to fix. Found by the sanitizers while running our testcases. Reported-By: gcc -fsanitize Git-Dch: Ignore 2014-09-26T22:12:14Z David Kalnischkies david@kalnischkies.de 2014-04-14T16:24:17Z urn:sha1:c46a36adaf51fc28464ea1a0e826c754ee60672b gnupg/gnupg2 can do verify just fine of course, so we don't need to use gpgv here, but it is what we always used in the past, so there might be scripts expecting a certain output and more importantly the output of apt-cdrom contains messages from gpg and even with all the settings we activate to prevent it, it still shows (in some versions) a quiet scary: "gpg: WARNING: Using untrusted key!" message. Keeping the use of gpgv is the simplest way to prevent it. We are increasing also the "Breaks: apt" version from libapt as it requires a newer apt-key than might be installed in partial upgrades.