| Age | Commit message (Collapse) | Author |
|---|
|
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
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
|
|
On Travis and co the default gpg implementation is gpg1 which for some
reason fails if a secret key which was already imported is imported
again. We would prefer it to be a NOP like gpg2 handles it so we crudely
check the error message. apt-key usually doesn't deal with secret keys –
it only learned to do it for manual testing and the integration
framework usage, so no public interface is effected.
Triggered-By: 4ce2f35248123ff2366c8c365ad6a94945578d66
Gbp-Dch: Ignore
|
|
Importing a new secret key into gpg(2) can be increadibly slow which
prolongs the test runs significantly – by caching the homedir we gain a
significant speedbonus as reimporting already present keys seems like a
far less costly operation.
Git-Dch: Ignore
|
|
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.
|
|
We report warnings from apt-key this way already since
29c590951f812d9e9c4f17706e34f2c3315fb1f6, so reporting errors seems like
a good addition. Most of those errors aren't really from apt-key
through, but from the code setting up and actually calling it which used
to just print to stderr which might or might not intermix them with
(other) progress lines in update calls. Having them as proper error
messages in the system means that the errors are actually collected
later on for the list instead of ending up with our relatively generic
but in those cases bogus hint regarding "is gpgv installed?".
The effective difference is minimal as the errors apply mostly to
systems which have far worse problems than a not as nice looking error
message, which makes this pretty hard to test – but at least now the
hint that your system is broken can be read in proper order (= there
aren't many valid cases in which the permissions of /tmp are messed up…).
LP: #1522988
|
|
|
|
On FreeBSD, readlink -f requires the last component
to exist.
|
|
In 105503b4b470c124bc0c271bd8a50e25ecbe9133 we got a warning implemented
for unreadable files which greatly improves the behavior of apt update
already as everything will work as long as we don't need the keys
included in these files. The behavior if they are needed is still
strange through as update will fail claiming missing keys and a manual
test (which the user will likely perform as root) will be successful.
Passing the new warning generated by apt-key through to apt is a bit
strange from an interface point of view, but basically duplicating the
warning code in multiple places doesn't feel right either. That means we
have no translation for the message through as apt-key has no i18n yet.
It also means that if the user has a bunch of sources each of them will
generate a warning for each unreadable file which could result in quite
a few duplicated warnings, but "too many" is better than none.
Closes: 834973
|
|
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.
|
|
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.
|
|
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.
|
|
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 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
|
|
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.
|
|
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.
|
|
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
|
|
|
|
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
|
|
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
|
|
We want to stop hard-depending on gnupg and for this it is essential
that apt-key isn't used in any critical execution path, which
maintainerscript are. Especially as it is likely that these script call
apt-key either only for (potentially now outdated cleanup) or still not
use the much simpler trusted.gpg.d infrastructure.
|
|
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
|
|
|
|
The presents (even of an empty) secring.gpg is indication enough for
gpg2 to tigger the migration code which not only produces a bunch of
output on each apt-key call, but also takes a while to complete as an
agent needs to be started and all that.
We workaround the first part by forcing the migration to happen always
in a call we forced into silence, but that leaves us with an agent to
start all the time – with a bit of reordering we can make it so that we
do not explicitly create the secring, but let gpg create it if needed,
which prevents the migration from being triggered and we have at least a
bit less of a need for an agent. Changes - even to public only keyrings
- still require one, but such actions are infrequent in comparison to
verification calls, so that should be a net improvement.
|
|
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…
|
|
In e75e5879 'replace "which" with "command -v" for portability' I missed
that command -v isn't actually required to be available in debian, so
for the 5 files we are using it:
Two (abicheck/run_abi_test & test/integration/framework) are called in
environments were I believe sh is at least dash or 'better' as the first
one is "interactive" for apt developers and the later is sourced by ~200
tests in the same directory run by hand and ci-services – for the later
we have pulled some uglier hacks for worser things already, so if there
should actually end up needing something more compatible we will notice
eventually (and the later actually had a command -v call for some time
already and nobody came running).
debian/rules and debian/apt.cron.daily I switched back to which as that
is more or less debian-specific or at least highly non-critical.
That leaves cmdline/apt-key.in with a bunch of calls where I will
implement that functionality in shell as this is relatively short-lived
as it is used to detect wget (for net-update, which Michael wants to
revive and in that process will properly use apt-helper instead of wget)
and to detect gpg vs. gpg2 systems, where the earlier is supposed to go
away in the longrun (or the later, but by replacing the earlier…).
[and this gpg/gpg2 detection is new in sid, so I have some sympathy for
that being a problem now.]
Thanks: Jakub Wilk for pointing out #747320
|
|
After e75e5879 the reason for an implicit dependency on debianutils
(which is essential for debian, but likely not on other systems) was
just two uses of run-parts, which can be replaced with the a lot more
portable find-piped-into-sort duo.
|
|
which is a debian specific tool packaged in debianutils (essential)
while command is a shell builtin defined by POSIX.
Closes: 807144
Thanks: Mingye Wang for the suggestion.
|
|
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.
|
|
Reported-By: codespell
|
|
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
|
|
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
|
|
It is sometimes handy to know how apt-key exactly called gpg, so adding
a pair of options to be able to see this if wanted is added. Two are
needed as some commands output is redirected to /dev/null, while sfor
others stdout is piped into another gpg call so in both cases you
wouldn't see all and hence you can choose.
Git-Dch: Ignore
|
|
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).
|
|
Conflicts:
apt-pkg/acquire-item.cc
cmdline/apt-key.in
methods/https.cc
test/integration/test-apt-key
test/integration/test-multiarch-foreign
|
|
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
|
|
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
|
|
Private temporary directories as created by e.g. libpam-tmpdir are nice,
but they are also very effective in preventing our priviledge dropping
to work as TMPDIR will be set to a directory only root has access to, so
working with it as _apt will fail. We circumvent this by extending our
check for a usable TMPDIR setting by checking access rights.
Closes: 765951
|
|
This prevents a failure in mktemp -d - it will blindly trust
TMPDIR and not use something else if the dir is not there.
|
|
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.
|
|
Git-Dch: Ignore
|
|
Some advanced commands can be executed without the keyring being
modified like --verify, so this adds an option to disable the mergeback
and uses it for our gpg calling code.
Git-Dch: Ignore
|
|
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.
|
|
For some advanced usecases it might be handy to specify the secret
keyring to be used (e.g. as it is used in the testcases), but specifying
it via a normal option for gnupg might not be available forever:
http://lists.gnupg.org/pipermail/gnupg-users/2013-August/047180.html
Git-Dch: Ignore
|
|
|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
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).
|
|
'apt-key help' and incorrect usage do not need a functioning gnupg
setup, as well as we shouldn't try to setup gnupg before we actually
test if it is available (and print a message if it is not).
|
|
gnupg has a hardlimit of 40 (at the moment) keyrings per invocation,
which can be exceeded with (many) repositories. That is rather
misfortune as the longrun goal was to drop gnupg dependency at some
point in the future, but this can now be considered missed and dropped.
It also means that 'apt-key adv' commands might not have the behaviour
one would expect it to have as it mainly operates on a big temporary
keyring, so commands modifying keys will break. Doing this was never a
good idea anyway through, so lets just hope nothing break too badly.
Closes: 733028
|
