apt/cmdline/apt-key.in, branch 1.3_rc2Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_rc22016-08-17T12:12:24Zallow spaces in fingerprints for 'apt-key del'2016-08-17T12:12:24ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-17T06:10:29Zurn: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.
add the gpg-classic variant to the gpgv/gnupg or-group2016-08-17T07:52:32ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-16T13:46:19Zurn:sha1:19fdf93d7363261227811a62157063081b9f1a5d
We need to support partial upgrades anyhow, so we have to deal with the
different versions and your tests try to ensure that we do, so we
shouldn't make any explicit higher requirements.
apt-key: ignore any error produced by gpgconf --kill2016-07-31T08:29:25ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-31T08:29:25Zurn:sha1:215598df84c092f801fe154e510c68fcc263b3ba
gpgconf wasn't always equipped with a --kill option as highlighted by
our testcases failing on Travis and co as these use a much older version
of gpg2. As this is just for cleaning up slightly faster we ignore any
error a call might produce and carry on. Use a recent enough gpg2
version if you need the immediate killing…
Gbp-Dch: Ignore
Reported-By: Travis CI
apt-key: kill gpg-agent explicitly in cleanup2016-07-31T07:56:26ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-31T07:27:19Zurn:sha1:4039798d971752325d097bfbdc9011b5e9efd29c
apt-key has (usually) no secret key material so it doesn't really need
the agent at all, but newer gpgs insist on starting it anyhow. The
agents die off rather quickly after the underlying home-directory is
cleaned up, but that is still not fast enough for tools like sbuild
which want to unmount but can't as the agent is still hanging onto a
non-existent homedir.
Reported-By: Johannes 'josch' Schauer on IRC
deprecate 'apt-key update' and no-op it in Debian2016-07-01T22:03:20ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-01T21:44:37Zurn:sha1:f4dcab0504a68595d9e95c953ce66f46f9ad30aa
Debian isn't using 'update' anymore for years and the command is in
direct conflict with our goal of not requiring gnupg anymore, so it
is high time to officially declare this command as deprecated.
warn if apt-key is used in scripts/its output parsed2016-07-01T20:00:52ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-01T20:00:52Zurn:sha1:08fcf9628806af202e555bd02b3611e4e9a3d757
apt-key needs gnupg for most of its operations, but depending on it
isn't very efficient as apt-key is hardly used by users – and scripts
shouldn't use it to begin with as it is just a silly wrapper. To draw
more attention on the fact that e.g. 'apt-key add' should not be used in
favor of "just" dropping a keyring file into the trusted.gpg.d
directory this commit implements the display of warnings.
alias apt-key list to finger2016-07-01T14:40:36ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-01T14:40:36Zurn:sha1:a5f9b45e4a67246f7af2c6fc62de9c531cd314a4
There is no real point in having two commands which roughly do the same
thing, especially if the difference is just in the display of the
fingerprint and hence security sensitive information.
Closes: 829232
apt-key: don't search PATH if command is a path already2016-06-14T11:55:33ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-14T11:55:33Zurn:sha1:ee385a36fe753272cadac0afd7f19b123a0c3d54apt-key: change to / before find to satisfy its CWD needs2016-06-02T11:35:28ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-02T09:12:39Zurn:sha1:0cfec3ab589c6309bf284438d2148c7742cdaf10
First seen on hurd, but easily reproducible on all systems by removing
the 'execution' bit from the current working directory and watching some
tests (mostly the no-output expecting tests) fail due to find printing:
"find: Failed to restore initial working directory: …"
Samuel Thibault says in the bugreport:
| To do its work, find first records the $PWD, then goes to
| /etc/apt/trusted.gpg.d/ to find the files, and then goes back to $PWD.
|
| On Linux, getting $PWD from the 700 directory happens to work by luck
| (POSIX says that getcwd can return [EACCES]: Search permission was denied
| for the current directory, or read or search permission was denied for a
| directory above the current directory in the file hierarchy). And going
| back to $PWD fails, and thus find returns 1, but at least it emitted its
| output.
|
| On Hurd, getting $PWD from the 700 directory fails, and find thus aborts
| immediately, without emitting any output, and thus no keyring is found.
|
| So, to summarize, the issue is that since apt-get update runs find as a
| non-root user, running it from a 700 directory breaks find.
Solved as suggested by changing to '/' before running find, with some
paranoia extra care taking to ensure the paths we give to find are really
absolute paths first (they really should, but TMPDIR=. or a similar
Dir::Etc::trustedparts setting could exist somewhere in the wild).
The commit takes also the opportunity to make these lines slightly less
error ignoring and the two find calls using (mostly) the same parameters.
Thanks: Samuel Thibault for 'finding' the culprit!
Closes: 826043
apt-key: add \n to dpkg-query --show --showformat2016-05-01T15:17:18ZCarsten Heycarsten@debian.org2016-05-01T15:06:29Zurn:sha1:2e49f51915d07a6ad85c7ee4380a1e51afaa3a17
Guarding against 'broken' greps not dealing with non-text inputs
"just in case" by making the input text with a proper newline.
[commit message by David Kalnischkies]
Reported-On: IRC
Git-Dch: Ignore