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
practise 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>
As an example of this in action:
> sudo ./scripts/pacman-key --populate
==> Verifying keyring file signatures...
==> Appending keys from allanbrokeit.gpg...
gpg: key EAE999BD: "Allan McRae <me@allanmcrae.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
==> Removing revoked keys from keyring...
removing key 5C2E46A0F53A76ED - Dan McGee <dpmcgee@gmail.com>
==> Updating trust database...
gpg: no need for a trustdb check
On Mon, Aug 15, 2011 at 8:10 AM, Allan McRae <allan@archlinux.org> wrote:
> 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.
Interesting thought. What happens here if a key is marked as OK in
foo.gpg, but "revoked" in bar-revoked, as might happen if someone
changes organizations?
Keeping arch and the TU and Dev groups in mind, you could see such a
situation. However, I don't believe we would ever put a key in the
revoked keyring unless we had really good reason to- this wouldn't
just happen if someone left the dev team for instance.
Not that timestamps are trustable in signatures themselves if the key
used to sign is trusted, but is there any way to say "this key is
valid but not if sigs using it were created after X time"? Clearly we
can get bogged down in this but something worth thinking about.
> 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
> practise probably by the key that signed the package providing these
practice
> 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>
> ---
> *doc/pacman-key.8.txt * * | * *8 ++-
> *scripts/Makefile.am * * *| * *1 +
> *scripts/pacman-key.sh.in | *149 +++++++++++++++++++++++-----------------------
> *3 files changed, 82 insertions(+), 76 deletions(-)
>
> diff --git a/doc/pacman-key.8.txt b/doc/pacman-key.8.txt
> index c8ce026..98ee6f6 100644
> --- a/doc/pacman-key.8.txt
> +++ b/doc/pacman-key.8.txt
> @@ -80,8 +80,12 @@ Options
> **-r, --receive* <keyserver> <keyid(s)>::
> * * * *Fetch the specified keyids from the specified key server URL.
>
> -*--reload*::
> - * * * Reloads the keys from the keyring package.
> +*--populate* [<keyring(s)>]::
> + * * * Reload the default keys from the (given) keyrings in +{pkgdatadir}/keyrings+.
(optionally provided) ?
> + * * * Each keyring is provided in a file foo.gpg that contains the keys for the foo
filenames in `foo.gpg` backticks usually is the convention.
> + * * * keyring. Optionally the file foo-revoked contains a list of revoked key ids
Optionally, <comma>
`foo-revoked.gpg` (forgot the extension here too). Or did I
misunderstand and this is a text file with IDs rather than an actual
keyring file with binary data? This might require some thought, it
looks like I did misunderstand.
"IDs" is the capitalization used in the gpg manpage.
On Mon, Aug 15, 2011 at 8:10 AM, Allan McRae<allan@archlinux.org> wrote:
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.
Interesting thought. What happens here if a key is marked as OK in
foo.gpg, but "revoked" in bar-revoked, as might happen if someone
changes organizations?
Yeah.. that could be interesting. At the moment I believe revoking
anywhere takes precedence, but I will need to double check that. I
think this is something that entirely undocmuented HoldKey option can be
used for.
Keeping arch and the TU and Dev groups in mind, you could see such a
situation. However, I don't believe we would ever put a key in the
revoked keyring unless we had really good reason to- this wouldn't
just happen if someone left the dev team for instance.
Not that timestamps are trustable in signatures themselves if the key
used to sign is trusted, but is there any way to say "this key is
valid but not if sigs using it were created after X time"? Clearly we
can get bogged down in this but something worth thinking about.
I have absolutely no idea if that is even possible with gpg...
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
practise probably by the key that signed the package providing these
practice
files. The --populate flag either updates the pacman keyring using all
keyrings in the directory or individual keyrings can be specified.
diff --git a/doc/pacman-key.8.txt b/doc/pacman-key.8.txt
index c8ce026..98ee6f6 100644
--- a/doc/pacman-key.8.txt
+++ b/doc/pacman-key.8.txt
@@ -80,8 +80,12 @@ Options
*-r, --receive*<keyserver> <keyid(s)>::
Fetch the specified keyids from the specified key server URL.
-*--reload*::
- Reloads the keys from the keyring package.
+*--populate* [<keyring(s)>]::
+ Reload the default keys from the (given) keyrings in +{pkgdatadir}/keyrings+.
(optionally provided) ?
+ Each keyring is provided in a file foo.gpg that contains the keys for the foo
filenames in `foo.gpg` backticks usually is the convention.
+ keyring. Optionally the file foo-revoked contains a list of revoked key ids
Optionally,<comma>
`foo-revoked.gpg` (forgot the extension here too). Or did I
misunderstand and this is a text file with IDs rather than an actual
keyring file with binary data? This might require some thought, it
looks like I did misunderstand.
"IDs" is the capitalization used in the gpg manpage.
Yes - the foo-revoked file is a list of key IDs rather than a keyring.
I just went with extending what was already implemented previously so I
guess this is how it is done in apt-key. When you say "requires more
thought" do you mean in the description or implementation?
+ for that keyring. These files are required to be signed (detached) by a
+ trusted PGP key.
verify_keyring_input() {
local ret=0;
+ local KEYRING_IMPORT_DIR='@pkgdatadir@/keyrings'
- # Verify signatures of related files, if they exist
- if [[ -r "${ADDED_KEYS}" ]]; then
- msg "$(gettext "Verifying official keys file signature...")"
- if ! "${GPG_PACMAN[@]}" --verify "${ADDED_KEYS}.sig"&>/dev/null; then
+ # Verify signatures of keyring files and association revocation files if they exist
+ msg "$(gettext "Verifying keyring file signatures...")"
+ local keyring
+ for keyring in ${KEYRINGIDS[@]}; do
+ if ! "${GPG_PACMAN[@]}" --verify "${KEYRING_IMPORT_DIR}/${keyring}.gpg.sig"&>/dev/null; then
So how do we do the initial bootstrap? Maybe we need a way (e.g.
command line option) to override the verification?
The initial bootstrap is going to require a user to manually add a
key(s) and give it some trust. That key(s) would then be used to sign
the keyring (and the package it is distributed in) for the rest of the
repo. I can not see any sane way around that step.
<snip>
+ for keyring in ${KEYRINGIDS[@]}; do
+ if [[ -f "${KEYRING_IMPORT_DIR}/${keyring}-revoked" ]]; then
+ while read key; do
+ local key_values name
+ key_values="$("${GPG_PACMAN[@]}" --quiet --with-colons --list-key "${key}" 2>/dev/null | grep ^pub | cut -d: -f5,10 --output-delimiter=' ')"
A comment describing this madness line would be nice.
Sure... note that is just an indent change so I will need to figure it
out too!
+ if [[ -n $key_values ]]; then
+ # The first word is the key_id
+ key_id="${key_values%% *}"
+ # the rest if the name of the owner
+ name="${key_values#* }"
+ if [[ -n ${key_id} ]]; then
+ # Mark this key to be deleted
+ removed_ids[$key_id]="$name"
+ fi
fi
- fi
- done< "${REMOVED_KEYS}"
- fi
+ done< "${KEYRING_IMPORT_DIR}/${keyring}-revoked"
+ fi
+ done
# List of keys that must be kept installed, even if in the list of keys to be removed
local HOLD_KEYS="$(get_from "$CONFIG" "HoldKeys")"
This is something I hadn't noticed before. How exactly does this hold
keys stuff work? man pacman-key, /hold shows me nothing.
Looks like this was never documented anywhere... My understanding is
that you can provide a list of keys to never be removed from the keyring
in using "HoldKey = " in pacman.conf.
Thinking about this, I'm not sure that is really an option for
pacman.conf, but it does seem like something that is a useful feature.
Suggestions for how it should be adjusted?
On Wed, Aug 17, 2011 at 9:49 PM, Allan McRae <allan@archlinux.org> wrote:
> On 18/08/11 08:48, Dan McGee wrote:
Hi, guys. I would like to add some notes on what Allan replied.
>> Optionally,<comma>
>> `foo-revoked.gpg` (forgot the extension here too). Or did I
>> misunderstand and this is a text file with IDs rather than an actual
>> keyring file with binary data? This might require some thought, it
>> looks like I did misunderstand.
>> "IDs" is the capitalization used in the gpg manpage.
>
> Yes - the foo-revoked file is a list of key IDs rather than a keyring. I
> just went with extending what was already implemented previously so I guess
> this is how it is done in apt-key. *When you say "requires more thought" do
> you mean in the description or implementation?
I don't remember exactly if it was in apt-get, but even if it isn't,
it's not that useful to have a real keyring for the revoked keys. What
is really needed is a way to identify a key to be removed. If we had a
real keyring we would just add another command to the pipe to get the
key IDs without any real gain. So, using the IDs from the start is all
that we need.
>>> * * * *# List of keys that must be kept installed, even if in the list of
>>> keys to be removed
>>> * * * *local HOLD_KEYS="$(get_from "$CONFIG" "HoldKeys")"
>>
>> This is something I hadn't noticed before. How exactly does this hold
>> keys stuff work? man pacman-key, /hold shows me nothing.
>
> Looks like this was never documented anywhere... *My understanding is that
> you can provide a list of keys to never be removed from the keyring in using
> "HoldKey = " in pacman.conf.
>
> Thinking about this, I'm not sure that is really an option for pacman.conf,
> but it does seem like something that is a useful feature. Suggestions for
> how it should be adjusted?
I think I forgot to write the corresponding documentation when I sent
the patch [1]. Sorry for that...
To summarize, when I made the patch, I worked with 3 sets of keys:
current, deprecated and removed. Current and deprecated would still be
added by the reload operation (now renamed to populate). Only keys in
the removed set would really be dropped from the keyring. In that
context, I thought of adding Holdkey as a way to allow the end user to
avoid having to re-add a needed key if it was marked to be removed.
My initial use case was based on the my personal premise that a
ex-developer's key would be removed by the time of his departure. In
that situation, maybe his key would still be useful for other personal
repositories he could keep maintaining elsewhere. But if a developer's
key is kept even after he leaves, the premise is not true anymore and
HoldKey would lose a potential use case. But maybe it is a matter of
distribution policy, so it could still be useful to have such an
option.