Create release signing key
(Use HTML orderedlist <ol> to mix procedure and preformatted blocks)
(Add info about mash)
|Line 102:||Line 102:|
$ gpg --send-keys E8E40FDE
$ gpg --send-keys E8E40FDE
== Verification ==
== Verification ==
Revision as of 15:00, 17 February 2010
At the beginning of each release under development a new package signing key is created for it. This key is used to prove the authenticity of packages built by Fedora and distributed by Fedora. This key will be used to sign all packages for the public test and final releases.
Sigul is the signing server which holds our keys. In order to make use of a new key, the key will have to be created and access to the key will have to be granted. The
change-passphrase commands are used.
$ sigul new-key --help usage: client.py new-key [options] key Add a key options: -h, --help show this help message and exit --key-admin=USER Initial key administrator --name-real=NAME_REAL Real name of key subject --name-comment=NAME_COMMENT A comment about of key subject --name-email=NAME_EMAIL E-mail of key subject --expire-date=YYYY-MM-DD Key expiration date $ sigul grant-key-access --help usage: client.py grant-key-access key user Grant key access to a user options: -h, --help show this help message and exit $ sigul change-passphrase --help usage: client.py change-passphrase key Change key passphrase options: -h, --help show this help message and exit
For example if we wanted to create the Fedora 13 signing key, we would do the following:
- Log into a system configured to run sigul client.
- Create the key using a strong passphrase when prompted
$ sigul new-key --key-admin jkeating --name-real Fedora \ --name-comment 13 \ --name-email email@example.com fedora-13
- Wait a while for entropy. This can take several minutes.
- Grant key access to Fedora Account holders who will be signing packages and protect it with a temporary a passphrase. For example, "CHANGEME."
$ sigul grant-key-access fedora-13 jwboyer
- Provide the key name and temporary passphrase to signers. If they don't respond, revoke access until they are ready to change their passphrase. Signers can change their passphrase using the
$ sigul change-passphrase fedora-13
The fedora-release package houses a copy of the public key information. This is used by rpm to verify the signature on files encountered. Currently the fedora-release package has a single key file named after the version of the key and the arch the key is for. To continue our example, the file would be named
RPM-GPG-KEY-fedora-13-primary which is the primary arch key for Fedora 13. To create this file, use the
get-public-key command from sigul:
$ sigul get-public-key fedora-13 > RPM-GPG-KEY-fedora-13-primary
Add this file to the repo, and remove the previous release's file.
$ cvs rm RPM-GPG-KEY-fedora-12-primary $ cvs add RPM-GPG-KEY-fedora-13-primary
Then make a new fedora-release build for rawhide (FIXME: this should be its own SOP)
fedoraproject.org/keys lists information about all of our keys. We need to let the webteam know we have created a new key so that they can add it to the list.
We do this by sending an email to firstname.lastname@example.org pointing to the viewvc http://cvs.fedoraproject.org/viewvc/fedora-release/RPM-GPG-KEY-fedora-13-primary?revision=1.1&root=fedora&view=co
This url will have to be refreshed for the right release and CVS version
sigulsign_unsigned is the script Release Engineers use to sign content in koji. This script has a hardcoded list of keys and aliases to the keys that needs to be updated when we create new keys.
Add the key details to the
KEYS dictionary near the top of the
sigulsign_unsigned.py script. It lives in Release Engineering's git repo at
git://git.fedorahosted.org/git/releng in the
scripts directory. You will need to know the key ID to insert the correct information:
$ gpg <key block from sigul get-public-key>
We upload the key to the public key servers when we create the keys. To do this, we need to get the ascii key block from sigul, determine the key ID, import they key into our local keyring, and then upload it to the key servers.
$ sigul get-public-key fedora-13 > fedora-13 $ gpg fedora-13 (The ID is the "E8E40FDE" part of 4096R/E8E40FDE) $ gpg --import fedora-13 $ gpg --send-keys E8E40FDE
Mash is the tool that composes our nightly trees, and as such it needs to know about the new key. This currently is done by checking mash out from git, editing the rawhide.mash file and sending the patch to the mash upstream.
$ git clone git://git.fedorahosted.org/git/mash $ cd mash $ vim configs/rawhide.mash <add key to front of keys = line> $ git commit -m 'Add new key' $ git send-email --to email@example.com HEAD^
Coordinate with Bill Nottingham to get a new build of mash done with the change.
We can verify that the key was created in sigul, the correct users have access to the key, the key was added to the fedora-release package, that the website was updated with the right key, that sigulsign_unsigned was properly updated, and that the key was successfully updated to the public key servers.
list-keys command to verify that the key was indeed added to sigul:
$ sigul list-keys Administrator's password: fedora-10 fedora-10-testing fedora-11 fedora-12 fedora-13
Our new key should be on the list. This command expects your administrative password.
list-key-users command to verify all the signers have access:
$ sigul list-key-users fedora-13 Key passphrase: jkeating jwboyer
This command expects your key passphrase for the key in question.
To verify that the key was added to this package correctly, download the latest build from koji and run rpm2cpio on it, then run gpg on the key file:
$ koji download-build --arch noarch --latest dist-f13 fedora-release fedora-release.noarch | 39 kB 00:00 ... $ rpm2cpio fedora-release-13-0.3.noarch.rpm |cpio -ivd ./etc/fedora-release ./etc/issue ./etc/issue.net ./etc/pki/rpm-gpg ./etc/pki/rpm-gpg/RPM-GPG-KEY-fedora ./etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-13-primary ./etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-i386 ./etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-ppc ./etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-ppc64 ./etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 ./etc/redhat-release ./etc/rpm/macros.dist ./etc/system-release ./etc/system-release-cpe ./etc/yum.repos.d ./etc/yum.repos.d/fedora-rawhide.repo ./etc/yum.repos.d/fedora-updates-testing.repo ./etc/yum.repos.d/fedora-updates.repo ./etc/yum.repos.d/fedora.repo ./usr/share/doc/fedora-release-13 ./usr/share/doc/fedora-release-13/GPL 57 blocks $ gpg etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-13-primary pub 4096R/E8E40FDE 2010-01-19 Fedora (13) <firstname.lastname@example.org>
You may wish to do this in a tempoary directory to make cleaning it up easy.
One can simply browse to http://fedoraproject.org/keys to verify that the key has been uploaded.
The best way to test whether or not the key has been added correctly is to sign a package using the key, like our newly built fedora-release package.
$ ./sigulsign_unsigned.py fedora-13 fedora-release-13-0.3 Passphrase for fedora-13:
The command should exit cleanly.
Public key servers
One can use the
search-keys command from gpg to locate the key on the public server:
$ gpg --search-keys "Fedora (13)" gpg: searching for "Fedora (13)" from hkp server subkeys.pgp.net (1) Fedora (13) <email@example.com> 4096 bit RSA key E8E40FDE, created: 2010-01-19 ...
Consider Before Running
Nothing at this time.