apt/test/integration/test-apt-key, branch 2.7.11

Support multiple keyrings in sources.list Signed-By

2018-09-11T11:16:11Z

A user can specify multiple fingerprints for a while now, so its seems counter-intuitive to support only one keyring, especially if this isn't really checked or enforced and while unlikely mixtures of both should work properly, too, instead of a kinda random behaviour.

Don't use gpg directly in apt-key test

2018-09-10T19:57:51Z

Reported-By: Guillem Jover Gbp-Dch: Ignore

ignore unsupported key formats in apt-key

2017-10-05T15:30:25Z

gpg2 generates keyboxes by default and users end up putting either those or armored files into the trusted.gpg.d directory which apt tools neither expect nor can really work with without fortifying backward compatibility (at least under the ".gpg" extension). A (short) discussion about how to deal with keyboxes happened in https://lists.debian.org/deity/2017/07/msg00083.html As the last message in that thread is this changeset lets go ahead with it and see how it turns out. The idea is here simply that we check the first octal of a gpg file to have one of three accepted values. Testing on my machines has always produced just one of these, but running into those values on invalid files is reasonabily unlikely to not worry too much. Closes: #876508

Call update from apt-key test for a strange path test

2017-06-26T21:31:15Z

We setup a "horrible" environment in the apt-key testcase to check all kinds of things, but we really should be making also at least a simple apt update call, as that in turn will call apt-key which is how apt-key is used in the non-testcase world, so that calling should be able to deal with such environments as well. Gbp-Dch: Ignore

add apt-key support for armored GPG key files (*.asc)

2016-11-24T23:15:12Z

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.

apt-key: warn instead of fail on unreadable keyrings

2016-08-25T10:42:36Z

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.

allow spaces in fingerprints for 'apt-key del'

2016-08-17T12:12:24Z

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-group

2016-08-17T07:52:32Z

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: change to / before find to satisfy its CWD needs

2016-06-02T11:35:28Z

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

gpgv: show always webportal error on NODATA

2016-05-08T17:46:34Z

gpg doesn't give use a UID on NODATA, which we were "expecting" (but not using for anything), but just an error number. Instead of collecting these as badsigners which will trigger a "invald signature" error with remarks like "NODATA 1" we instead adapt a message similar to the NODATA error of a clearsigned file (which is actually not reached anymore as we split them up, which fails with a NOSPLIT error, which uses the same general error message). In other words: Not a security relevant change, just a user experience improvement as we now point them to the most likely cause of the problem instead of saying "invalid signature" which would point them in the direction of the archive being broken (for everyone) instead. Closes: 823746