We're putting the cart ahead of the horse a bit here. Given that our
keyring is not one where everything is implicitly trusted (ala gpgv),
keeping or deleting a key has no bearing on its trusted status, only
whether we can actually verify things signed by said key.
If we need to address this down the road, we can find a solution that
works for the problem at hand rather than trying to solve it now before
signing is even widespread.
Signed-off-by: Dan McGee <dan@archlinux.org>
Unlike our protégé apt-key, removing a key from our keyring is not
sufficient to prevent it from being trusted or used for verification. We
are better off flagging it as disabled and leaving it in the keyring so
it cannot be reimported or fetched at a later date from a keyserver and
continue to be used.
Implement the logic to disable the key instead of delete it, figuring
out --command-fd in the process.
Note that the surefire way to disable a key involves including said key
in the keyring package, such that it is both in foobar.gpg and
foobar-revoked.
Signed-off-by: Dan McGee <dan@archlinux.org>
This finishes the cleanup started in 710e83999b. We can do a straight
import from another keyring rather than all the funky parsing and piping
business we were doing.
Signed-off-by: Dan McGee <dan@archlinux.org>
Otherwise we're hiding extremely relevant bits like this one:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Signed-off-by: Dan McGee <dan@archlinux.org>
* Ensure usage message is indented correctly
* Show short filenames for both the gpg keyring and revocation file
Signed-off-by: Dan McGee <dan@archlinux.org>
This also renames '--receive' to '-recv-keys' to match the wrapped gpg
option name, rather than invent a new one, now that the calling
convention is the same.
Signed-off-by: Dan McGee <dan@archlinux.org>
We were using the mystical [<foobar>] options which is some sort of
cross between a <required> argument and an [optional] one. Remove this
madness and do some other general cleanup/consistency work in the
manpage.
Signed-off-by: Dan McGee <dan@archlinux.org>
This allows local signing of a given key to help establish the web of
trust rooted at the generated (or imported) master key.
Signed-off-by: Dan McGee <dan@archlinux.org>
This enables pacman-key, during --init, to generate a single secret key
for the pacman keyring if one is not present. This will be used as the
root of the web of trust for those that do not wish to manage it with
their own key, as will be the default.
This does not preclude later adding other secret keys to the keyring, or
removing this one- we simply ensure you have at least one secret key
available.
Signed-off-by: Dan McGee <dan@archlinux.org>
Any option that flips UPDATEDB=1 doesn't work right now due to what we
thought was a good idea in commit cab1379a1a. Fix this by not
including the update operation in the option count and special casing
it where necessary.
Also, bring back the helpful "Updating trust database" message.
Signed-off-by: Dan McGee <dan@archlinux.org>
This adds a add_gpg_conf_option() helper function which tries to be
intelligent and only add not found options, and those which have not
been explicitly commented out.
The new options added are 'no-greeting', 'no-permission-warning', and a
default 'keyserver'.
Signed-off-by: Dan McGee <dan@archlinux.org>
* secring.gpg can be 600, readable by root user only
* ensure grep for lock-never option in check_keyring doesn't catch comments
Signed-off-by: Dan McGee <dan@archlinux.org>
The HoldKey option was undocumented and was not suited for pacman.conf.
Instead use the file "/etc/pacman.d/gnupg/heldkeys" to contain a list
of keys not to be removed from the pacman keyring with the --populate
option.
Signed-off-by: Allan McRae <allan@archlinux.org>
After most operations that touch the keyring, it is a good idea to
always run a check on the trustdb as this prevents gpg complaining
on later operations.
Inspiration-from: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
The optimization of only importing keys that were not to be later
revoked was a not smart enough. For example, if a key was
in both a repos keyring and its revoke list, alternate runs of
pacman-key --populate would add then remove the key from the pacman
keyring. This problem is made worse when considering the possibility
of multiple keyrings being imported.
Instead, import all keys followed by the revoking of all keys. This
may result in a key being added then revoked, but that is not much of
an issue given that is a very fast operation.
Signed-off-by: Allan McRae <allan@archlinux.org>
The current --reload option, apart from being non-clear in its naming,
is very limited in that only one keyring can be provided. A distribution
may want to provide multiple keyrings for various subsets of its
organisation or custom repo providers may also want to provide a keyring.
This patch adds a --populate option that reads keyrings from (by default)
/usr/share/pacman/keyrings. A keyring is named foo.gpg, with optional
foo-revoked file providing a list of revoked key ids. These files are
required to be signed (detached) by a key trusted by pacman-key, in
practice probably by the key that signed the package providing these
files. The --populate flag either updates the pacman keyring using all
keyrings in the directory or individual keyrings can be specified.
Signed-off-by: Allan McRae <allan@archlinux.org>
The current --list option outputed the keys and all their signatures
which can be overly verbose. It also did not take a list of keys on
the command line to limit its output (although the code suggests that
was intended).
That patch brings consistency with gpg, providing --list-keys and
--list-sigs options that function equivalently to those provided by
gpg.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Currently, pacman-key allows the user to import their keys using the --add
option. However, no similar functionality exists for importing ownertrust
values.
The --import-trustdb option takes a list of directories and imports ownertrust
values if the directories have a trustdb.gpg database.
The --import option takes a list of directories and imports keys from
pubring.gpg and ownertrust values from trustdb.gpg. Think of it as a combination
of --add and --import-trustdb
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Allows the commands to safely handle any possible arguments
Signed-off-by: DJ Mills <danielmills1@gmail.com>
Allan: rebase patch
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is a cleaner expression of the same information.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Makes sure that the pacman keyring is readable and that the user
has permissions to create a lock file if lock-never is not specified
in the gpg.conf file.
Signed-off-by: Allan McRae <allan@archlinux.org>
Add an --init option that ensures that the pacman keyring has all
the necessary files and they have the correct permissions for being
read as a user.
Signed-off-by: Allan McRae <allan@archlinux.org>
This function had a variety of pitfalls, including the inability to
successfully find a key=value pair where no whitespace surrounded the
equals sign. Make it more robust by splitting the line on the equals
itself, and performing whitespace trimming on the resulting key/value
pair.
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Follow the example of gpg and only allow a single operation to be
specified each time. Prevents having to deal with conflicting
variable names and potential issues due to the order in which the
operations are run.
Signed-off-by: Allan McRae <allan@archlinux.org>
This moves the processing of the --edit-key and --receive options
to functions, keeping the final option processing to be all single
line statements.
Also rework the --edit-key option to validate all input before
processing.
Signed-off-by: Allan McRae <allan@archlinux.org>
This commit correctly redirects to /dev/null the output of several
commands that get executed on logic checks.
Original-patch-by: Denis A. Altoé Falqueto <denisfalqueto@gmail.com>
Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
This keeps the naming of the option more consistent with what is
actually being called by gpg.
Original-patch-by: Denis A. Altoé Falqueto <denisfalqueto@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
This commit adds quotes to several variable assignments. Unquoted values
can cause problems on several occasions if the value is empty. It is
safer to have every assignment quoted.
Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>
The conversion to using parse_options causes this option to break.
It is preferable to remove the option rather than fix it as it is
simply a wrapper for "gpg --homedir @sysconfdir@/pacman.d/gnupg".
Any user using more advanced keyring management than provided by
pacman-key can manage to point gpg at the right place themselves...
How to manually edit the keyring with gpg will instead be documented
in the man page in a later commit.
Signed-off-by: Allan McRae <allan@archlinux.org>
The pacman-key script is complicated enough to warrent usage of the
parse_options script. This is especially helpful in dealing with
all the configuration file override flags as the no longer need to
be specified first. It also allows us to do the right thing early
with --help/--version and no option cases cleanly. This change also
makde the check for root privileges only occur on operations where
they are needed.
This patch is inspired by and supercedes some patches submitted by
Denis A. Altoé Falqueto and Ivan Kanakarakis who were altering the
previous option handling in an attempt to deal with the above issues.
Signed-off-by: Allan McRae <allan@archlinux.org>
The lone quotation mark in "pacman's" causes issues for some syntax
highlighting. Change the printing of the nessage from echo to printf
so we can invisibly escape it.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
vim recognises what type of shell script it's dealing with by looking at
the shebang. If detection fails it falls back to sh which doesn't
support some bash features. Adding a normal, possibly broken, shebang
which gets fixed by the Makefile allows vim to detect bash syntax.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Signed-off-by: Dan McGee <dan@archlinux.org>
This is the first step at separating the pacman message catalog and the
scripts message catalog. Makefiles, configure.ac, and other such files
are adjusted accordingly, as well as renaming files. The TEXTDOMAIN of
scripts is also adjusted.
Note that no actual pot or po files get changed here; these will get
pruned in a future commit so each catalog contains only the necessary
messages.
Signed-off-by: Dan McGee <dan@archlinux.org>
Move the common output formatting functions into a separate
library file and import that into each script. makepkg is
excluded due to its additional color formatting.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
This commit replaces the find_config() function with the get_from()
function. get_from expects two arguments, the first is the file to
read and the second is the key to look for in the given file.
get_from returns the first matching value for the given key. The
file is expected to be in the format:
key = value
Each of 'key' 'equal sign' 'value' can be surrounded be random
whitespace.
Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
If the user provides an unsupported command, inform the user that this
switch is unknown, display usage and exit.
Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
The help message changed to match the one rankmirrors script has.
It's clearer as to what the --help switch does.
Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Use mode 755, so non-root users can see inside.
Add "--no-permission-warning" to GPG_PACMAN to suppress the noise that
otherwise comes of not using mode 700 - this is not private data.
GPGme turns out not to issue this warning itself, so no problem there.
TODO: should non-root users be allowed to use the read-only operations
(--list, --export, --finger)?
Signed-off-by: Ray Kohler <ataraxia937@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Make it actually like all our other tools rather than some homegrown
format. Also make it translator friendly by not wrapping messages across
lines in different strings.
Signed-off-by: Dan McGee <dan@archlinux.org>
Make the usage output display nicely on 80 character width terminals.
Also fix parsing of "-h" and "-v" options and avoid root check when
run with no commands.
Signed-off-by: Allan McRae <allan@archlinux.org>
The --reload command was refactored to allow a more flexible management.
There are two sets of keys that will be added, one that will be
removed and one that will be kept.
The set of keys to be kept are configured in pacman.conf, with the
option HoldKeys, with the same meaning of HoldPkgs. It can be repeated
and several values can be put in the same entry.
The new behavior allows a key to be marked for removal, but the user
can decide if that key must be kept. For example, if a developer has
a public repository, signed with his own key, that key must be added
to the HoldKeys option. If the key is marked for removal from pacman's
keyring, it will not be removed for the users that have configured
HoldKeys correctly.
There are other minor fixes, mainly in the handling of --add command
when there is no aditional parameter. In that case, pacman-key will
behave just like gpg, adding the contents of stdin into pacman's keyring.
Signed-off-by: Denis A. Altoé Falqueto <denisfalqueto@gmail.com>
The script pacman-key will manage pacman's keyring. It imports, exports,
fetches from keyservers, helps in the process of trusting and updates
the trust database.
Signed-off-by: Denis A. Altoé Falqueto <denisfalqueto@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
