Project:Gentoo-keys/Spec-check

From Gentoo Wiki
Jump to: navigation, search

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 -h
usage: 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:

Note
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-devs
Gkey 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-devs

This 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.

Note
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.
Note
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)