apt/test/integration/test-apt-key, branch 1.4.4Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.4.42016-11-24T23:15:12Zadd apt-key support for armored GPG key files (*.asc)2016-11-24T23:15:12ZDavid Kalnischkiesdavid@kalnischkies.de2016-11-13T19:52:18Zurn: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.
apt-key: warn instead of fail on unreadable keyrings2016-08-25T10:42:36ZDavid Kalnischkiesdavid@kalnischkies.de2016-08-25T10:42:36Zurn: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.
allow 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: 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
gpgv: show always webportal error on NODATA2016-05-08T17:46:34ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-08T17:46:34Zurn:sha1:2fac0dd5a7a62b67a869cd4c71c9d09159aaa31d
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 key2016-05-01T08:50:24ZDavid Kalnischkiesdavid@kalnischkies.de2016-04-28T22:31:49Zurn:sha1:fb7b11ebb852fa255053ecab605bc9cfe9de0603
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 expansion2016-03-06T09:16:59ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-06T09:16:59Zurn:sha1:031a3f254a2a73b2843ead28a2481b63ec1d7244
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 testcases2015-12-19T22:04:34ZDavid Kalnischkiesdavid@kalnischkies.de2015-12-18T12:17:11Zurn:sha1:785cb6fc843f4751ff9c57dcdf375ad061e83f36
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-key2015-12-19T22:04:34ZDavid Kalnischkiesdavid@kalnischkies.de2015-12-17T16:41:11Zurn:sha1:bc8f83a5afd858206efe518c31bbb1ac948a39a3
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…