summaryrefslogtreecommitdiff
path: root/test/integration/test-apt-key
Commit message (Collapse)AuthorAgeFilesLines
* Support multiple keyrings in sources.list Signed-ByDavid Kalnischkies2018-09-111-0/+16
| | | | | | | 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 testDavid Kalnischkies2018-09-101-1/+1
| | | | | Reported-By: Guillem Jover <guillem@debian.org> Gbp-Dch: Ignore
* ignore unsupported key formats in apt-keyDavid Kalnischkies2017-10-051-40/+61
| | | | | | | | | | | | | | | | | | | 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 testDavid Kalnischkies2017-06-261-0/+13
| | | | | | | | | | 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)David Kalnischkies2016-11-251-72/+109
| | | | | | | | | | | | 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 keyringsDavid Kalnischkies2016-08-251-0/+24
| | | | | | | | | | | 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'David Kalnischkies2016-08-171-0/+8
| | | | | | 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-groupDavid Kalnischkies2016-08-171-8/+26
| | | | | | 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 needsDavid Kalnischkies2016-06-021-106/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 NODATADavid Kalnischkies2016-05-081-2/+4
| | | | | | | | | | | | | | | | | 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
* don't show NO_PUBKEY warning if repo is signed by another keyDavid Kalnischkies2016-05-011-1/+53
| | | | | | | | | | | | | | | Daniel Kahn Gillmor highlights in the bugreport that security isn't improving by having the user import additional keys – especially as importing keys securely is hard. The bugreport was initially about dropping the warning to a notice, but in given the previously mentioned observation and the fact that we weren't printing a warning (or a notice) for expired or revoked keys providing a signature we drop it completely as the code to display a message if this was the only key is in another path – and is considered critical. Closes: 618445
* add test for apt-key 0xKEY and use parameter expansionDavid Kalnischkies2016-03-061-0/+11
| | | | | | | | | Fixed in f7bd44bae0d7cb7f9838490b5eece075da83899e already, but the commit misses the Closes tag and while we are at it we can add a simple regression test and micro-optimize it a bit. Thanks: James McCoy for the suggestion. Closes: 816691
* tests: support gpg2 properly in all testcasesDavid Kalnischkies2015-12-191-29/+0
| | | | | | | | | The output changes slightly between different versions, which we already dealt with in the main testcase for apt-key, but there are two more which do not test both versions explicitly and so still had gpg1 output to check against as this is the default at the moment. Git-Dch: Ignore
* avoid evaluating shell in paths used in apt-keyDavid Kalnischkies2015-12-191-0/+8
| | | | | | | | | | | | apt-key creates internally a script (since ~1.1) which it will call to avoid dealing with an array of different options in the code itself, but while writing this script it wraps the values in "", which will cause the shell to evaluate its content upon execution. To make 'use' of this either set a absolute gpg command or TMPDIR to something as interesting as: "/tmp/This is fü\$\$ing cràzy, \$(man man | head -n1 | cut -d' ' -f1)\$!" If such paths can be encountered in reality is a different question…
* tests: support spaces in path and TMPDIRDavid Kalnischkies2015-12-191-2/+2
| | | | | | | This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore
* deal with spaces in path, command and filepaths in apt-keyDavid Kalnischkies2015-09-141-7/+8
| | | | | | | | Filenames we get could include spaces, but also the tmpdir we work in and the failures we print in return a very generic and unhelpful… Properly supporting spaces is a bit painful as we constructed gpg command before, which is now moved to (multilevel) calls to temporary scripts instead.
* implement Signed-By without using gpg for verificationDavid Kalnischkies2015-08-101-0/+1
| | | | | | | | | | The previous commit returns to the possibility of using just gpgv for verification proposes. There is one problem through: We can't enforce a specific keyid without using gpg, but our acquire method can as it parses gpgv output anyway, so it can deal with good signatures from not expected signatures and treats them as unknown keys instead. Git-Dch: Ignore
* merge keyrings with cat instead of gpg in apt-keyDavid Kalnischkies2015-08-101-1/+1
| | | | | | | | | | | | | | | | | | | If all keyrings are simple keyrings we can merge the keyrings with cat rather than doing a detour over gpg --export | --import (see #790665), which means 'apt-key verify' can do without gpg and just use gpgv as before the merging change. We declare this gpgv usage explicit now in the dependencies. This isn't a new dependency as gnupg as well as debian-archive-keyring depend on and we used it before unconditionally, just that we didn't declare it. The handling of the merged keyring needs to be slightly different as our merged keyring can end up containing the same key multiple times, but at least currently gpg does remove only the first occurrence with --delete-keys, so we move the handling to a if one is gone, all are gone rather than an (implicit) quid pro quo or even no effect. Thanks: Daniel Kahn Gillmor for the suggestion
* support gpg 2.1.x in apt-keyDavid Kalnischkies2015-08-101-51/+64
| | | | | | | | | | | | | | | | | | The output of gpg slightly changes in 2.1 which breaks the testcase, but the real problem is that this branch introduces a new default keyring format (which is called keybox) and mixing it with simple keyrings (the previous default format) has various problems like failing in the keybox to keyring import (#790665) or [older] gpgv versions not being able to deal with keyboxes (and newer versions as well currently: https://bugs.gnupg.org/gnupg/issue2025). We fix this by being a bit more careful in who creates keyrings (aka: we do it or we take a simple keyring as base) to ensure we always have a keyring instead of a keybox. This way we can ensure that any version combination of gpv/gpgv2 and gnupg/gnupg2 without doing explicit version checks and use the same code for all of them. Closes: 781042
* implement Signed-By option for sources.listDavid Kalnischkies2015-08-101-2/+35
| | | | | | | | | | 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).
* Merge branch 'debian/jessie' into debian/experimentalDavid Kalnischkies2015-04-191-0/+7
|\ | | | | | | | | | | | | | | | | Conflicts: apt-pkg/acquire-item.cc cmdline/apt-key.in methods/https.cc test/integration/test-apt-key test/integration/test-multiarch-foreign
| * keyids in "apt-key del" should be case-insensitiveDavid Kalnischkies2015-04-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | gnupg is case-insensitive about keyids, so back then apt-key called it directly any keyid was accepted, but now that we work more with the keyid ourself we regressed to require uppercase keyids by accident. This is also inconsistent with other apt-key commands which still use gnupg directly. A single case-insensitive grep and we are fine again. Closes: 781696
| * support long keyids in "apt-key del" instead of ignoring themJames McCoy2014-11-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | apt-key given a long keyid reports just "OK" all the time, but doesn't delete the mentioned key as it doesn't find the key. Note: In debian/experimental this was closed with 29f1b977100aeb6d6ebd38923eeb7a623e264ffe which just added the testcase as the rewrite of apt-key had fixed this as well. Closes: 754436
* | test exitcode as well as string equalityDavid Kalnischkies2015-03-161-2/+2
| | | | | | | | | | | | | | | | We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore
* | tests: enhance output of grep and test failsDavid Kalnischkies2014-10-261-7/+7
| | | | | | | | Git-Dch: Ignore
* | ensure world-readability for trusted.gpg in postinstDavid Kalnischkies2014-10-021-0/+7
| | | | | | | | | | | | | | | | | | | | apt-key creates trusted.gpg if it needs it with 644 nowadays, but before it ensured this, it was gpg creating it, which gives it by default 600. Not a problem as long as our gpgv is run as root, but now that we drop privileges we have to ensure that we can also read trusted.gpg files created by earlier apt-key versions. Closes: 647001
* | ensure apt-key del handles 16-byte key idsJames McCoy2014-09-271-0/+8
| | | | | | | | | | | | | | The original patch does not apply against the rewritten apt-key, but an additional test doesn't hurt. Closes: 754436
* | use only one --keyring in gpg interactionsDavid Kalnischkies2014-09-271-18/+39
| | | | | | | | | | | | | | | | | | We were down to at most two keyrings before, but gnupg upstream plans dropping support for multiple keyrings in the longrun, so with a single keyring we hope to be future proof – and 'apt-key adv' isn't a problem anymore as every change to the keys is merged back, so we have now the same behavior as before, but support an unlimited amount of trusted.gpg.d keyrings.
* | allow to specify fingerprints in 'apt-key del'David Kalnischkies2014-09-271-0/+8
| |
* | add a test for apt-key export{,all}David Kalnischkies2014-09-271-0/+7
| | | | | | | | Git-Dch: Ignore
* | support gnupg2 as drop-in replacement for gnupgDavid Kalnischkies2014-09-271-83/+108
|/ | | | | | If both are available APT will still prefer gpg over gpg2 as it is a bit more lightweight, but it shouldn't be a problem to use one or the other (at least at the moment, who knows what will happen in the future).
* let apt-key del work better with softlink and single key keyringsDavid Kalnischkies2013-08-121-0/+68
| | | | | | | Having fragement files means there is a good chance that there is one key per keyring, so deal with that as well as with setups in which keyrings are linked into trusted.gpg.d as we can't just modify those files (they might be in /usr for example).
* make the keyring locations in apt-key configurableDavid Kalnischkies2013-08-121-0/+39
Might come in handy for more than just a simple testcase.