Project:Gentoo-keys/Spec-check
Introduction
spec-check is a sub-command passed to the gkeys command to compare OpenPGP keys to the chosen specification (NOTE: not yet selectable) and identify problems (if any) that need to be corrected in order to consider the keys compliant with GLEP 63.
Subcommand help
root #gkeys spec-check -husage: gkeys spec-check [-h] [-C CATEGORY] [-n NICK] [-N [NAME [NAME ...]]]
[-f FINGERPRINT [FINGERPRINT ...]]
[-i KEYID [KEYID ...]] [-K [KEYS [KEYS ...]]]
[-r KEYDIR] [-k KEYRING]
Check if keys meet specifications requirements
optional arguments:
-h, --help show this help message and exit
-C CATEGORY, --category CATEGORY
The key or seed directory category to use or update
-n NICK, --nick NICK The nick associated with the the key
-N [NAME [NAME ...]], --name [NAME [NAME ...]]
The name of the the key
-f FINGERPRINT [FINGERPRINT ...], --fingerprint FINGERPRINT [FINGERPRINT ...]
The fingerprint(s) of the the key or subkey
-i KEYID [KEYID ...], --keyid KEYID [KEYID ...]
The long keyid of the gpg key to search for
-K [KEYS [KEYS ...]], --keys [KEYS [KEYS ...]]
The fingerprint(s) of the primary keys in the keyring.
-r KEYDIR, --keydir KEYDIR
The keydir to use, update or search for/in
-k KEYRING, --keyring KEYRING
The name of the keyring to use for verification, etc.
Fetching the gentoo-devs seed file
Before checking the keys, make sure the gentoo-devs seed file has been installed. To do this, execute the following commands as root:
This is a user or reference seed file used to install the Gentoo developers (public) gpg keys. The spec-check sub command can work on any -C, --category keyring(s) defined and installed.
root #gkeys fetch-seed -C gentoo-devsGkey task results: Verification succeeded.: /var/lib/gentoo/gkeys/seeds/gentoo-devs.seeds Key info...............: Gentoo-Linux Gentoo-keys Project Signing Key <gkeys>, 0xA41DBBD9151C3FC7 category, nick.....: gentoo gkeys Fetch operation completed
After the fetch finishes run the following command:
root #gkeys install-key -C gentoo-devsThis should output a long list of metadata for each Gentoo Developer and their associated OpenPGP keys. It will proceed to download each key from a keyserver; the process can take a while (about ten minutes).
Checking keys
Keys can be checked using the following command:
user $gkeys spec-check -C gentoo-devs -n <developer_nickname>There are other options (accessible with -h), but the above command is what is needed to check an individual developer's gpg key.
If a key passes the check the output should look similar to the following:
user $gkeys spec-check -C gentoo -n gkeys
Checking keys...
gkeys, Gentoo-Linux Gentoo-keys Project Signing Key: 0x825533CBF6CD6C97
==============================================
----------
Fingerprint......: D2DE1DBBA0F43EBA341B97D8825533CBF6CD6C97
Key type ........: PUB Capabilities.: cSC
Algorithm........: Pass Bit Length...: Pass
Create Date......: Pass Expire Date..: Pass
Key Version......: Pass Validity.....: -, Unknown
Days till expiry.: 855
Capability.......: Pass
Qualified ID.....: Pass
This primary key.: Pass
----------
Fingerprint......: C287167569B3C1F9E9CED677A41DBBD9151C3FC7
Key type ........: SUB Capabilities.: s sign
Algorithm........: Pass Bit Length...: Pass
Create Date......: Pass Expire Date..: Pass
Key Version......: Pass Validity.....: -, Unknown
Days till expiry.: 855
Capability.......: Pass
Qualified ID.....: Pass
This subkey......: Pass
Key summary
primary..........: Pass signing subkey: Pass
encryption subkey: No authentication subkey: No
SPEC requirements: Pass
No Encryption capable subkey (Notice only):
Gentoo-Linux Gentoo-keys Project Signing Key <gkeys>: D2DE1DBBA0F43EBA341B97D8825533CBF6CD6C97
SPEC Approved:
Gentoo-Linux Gentoo-keys Project Signing Key <gkeys>: D2DE1DBBA0F43EBA341B97D8825533CBF6CD6C97
Gkey task results:
Found Failures:
-------
Revoked................: 0
Invalid................: 0
No Signing subkey......: 0
No Encryption subkey...: 1
Algorithm..............: 0
Bit length.............: 0
Expiry.................: 0
Expiry Warnings........: 0
SPEC requirements......: 0
=============================
SPEC Approved..........: 1
Notice the "SPEC Approved" field in the last line of the output says 1.
All spec requirements will show a pass/fail grade, while non-spec check indicators will be Yes/No and are for user information only. That is why even though it shows the lack of an encryption sub-key No Encryption subkey...: 1 in the failures summary. It still shows that the key passes spec SPEC Approved..........: 1.
In the above example, the Gentoo-keys team key is for official use, like signing the key seed file(s). For that reason we do not need an encryption subkey. Most users however should have an encryption subkey to be used to receive encrypted email, etc. For that reason we recommend users add an encryption subkey.
For a developer editing his key to bring it up to the GLEP 63 standard, remember, the gentoo-devs category is the public key information only as received from the keyservers. So, this will only reflect the state of the key as of the last refresh of the key with the keyservers. In order for a developer/user to have gkeys interact with an active secret/public gpg keyring, you must configure/move or import the secret keyring into the gkeys keyring structure, then use that category and nick, etc. In that way gkeys can interact with an active secret keyring to spec-check changes before uploading those changes to the keyservers. Currently we do not have an automated sub-command for doing this within gkeys. (stay tuned for updates and instructions how to do this)