This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Keysigning at CloudStack Collaboration Conference
Skip to end of metadata
Go to start of metadata


As you've likely noticed we are having a keysigning event on Sunday at the CloudStack Collaboration Conference This will explain the why and how.


Apache CloudStack uses PGP signatures as one way of insuring and verifying the integrity of our releases. This works best when there is a well established web of trust ( ) that verifies the authenticity of the keys in question.


The keysigning process essentially allows you to verify that the identity claimed by an individual and their key is valid, and then sign that key to vouch for it.

You'll obviously need a PGP key of your own. The Fedora Project has excellent documentation for doing this in Linux:

For other operating systems see this page:

Once you have your keypair you should send your public key to before Sunday.

$ gpg -armor --export KEY_ID > mykey$USER.asc Then just copy and paste the contents of mykey.asc in an e-mail to me. The key list, and a PGP (or GnuPG) keyring export will be available for your convenience

The actual event:

1. Everybody gets a print-out of the key list. I will make those and have them available.
2. The key entries on the printout are numbered. All participants line up in the order of their keys.
3. The list will also be on the projection screen (assuming we get a projector, and get it to work in a timely fashion). You verify that your entry on the printout is correct: that the key ID, fingerprint and name + e-mail information match what you submitted. You also verify that your entry on the printout is the same as your entry on the screen.
4. I will call out the name of each participant, in order. When your name is called, tell all participants loudly whether your information as verified in step 3 is correct. Stand up and wave your arms if you want to, it's very important that the other participants see and hear you assert that this key is yours.
5. As participants positively verify their information, check whether their entry on the screen matches their entry on your printout. If so, you can place a check mark in the first of the two boxes at the right of your printout. Why do we do this? To make sure we all have the same list, and that the list is correct. You are verifying that I didn't make any mistakes compiling the list, or that I didn't nefariously doctor anyone's key.
6. Once everyone's key data has been verified, the fun part starts. Everybody gets up, and forms a line in the order in which you appear on the list. Once the line is formed, we'll double it: the first person in the line walks past the line until he or she ends up next to the last person, and everyone follows until we have a double line, half as long. Then, everyone makes a quarter turn so that they face the person next to them rather than the back of the person in front.
7. Now, everyone in the line is going to identify every other participant. Start with the person standing (conveniently) right in front of you, then move one person to the right and repeat until you have met everyone in line. The line will fold upon itself in caterpillar fashion: once you reach the end just turn around and start going to the other side (the next person you "meet" will be your neighbor). As you make positive identification of a person, you place a check mark on their line in the second box at the right of your printout. How do you identify people? That is up to you. Some folks check each other's passport or driver's license, but that means you trust the government to provide positive identification. And who trusts the government anymore these days? Some folks just know each other, or, if they haven't met before the conference, have gotten to know each other well enough to assert that they know who they are. It's really up to you, and if you can't identify the other person to your liking, don't place that checkbox and don't sign their key.
8. After everyone has met everyone else, you should have a list with a bunch of checkmarks in the right columns. Put this list in your pocket. Back in your hotel room, pull out the list, and sign the keys that you gave two checkmarks. Then, upload the signed key to the following two keyservers:
Then, send the owner of the key a signed, encrypted e-mail telling them that you have signed their key. Hopefully they will do you the same favor.

What you should bring:

Yourself. Obviously.
A pen. Bring two, so you can give one to your neighbor in line who forgot to bring one.
Something to identify yourself with. Your face, your voice, unique pheromone pattern, etc. The better you can convince your fellow participants that it's really you, the more signatures you will get.


After the event at your leisure, you can sit down and actually sign the keys using the following process:
Step 1: Get a copy of the key

Normally, you'll be working from a keyserver. However if you are signing the key that is not available on a keyserver, you can use simply import the key with gpg --import. If you are working with a keyserver, the following command will download the key from the keyserver into your public keyring.

bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>
If you get a read error, it means the keyserver is overloaded. Please, try again in a few seconds.

Step 2: Fingerprint and Verify the key

bash$ gpg --fingerprint <Key_ID>
GPG will print out the fingerprint of the Key with <Key_ID> (the key you just downloaded). Check the fingerprint against the checklist that you where given at the party. Note: Don't check the fingerprint on your checklist against the fingerprint on the web page as the server may not send you the same key it displays on the web page.

Step 3: Sign the key

bash$ gpg --sign-key <Key_ID>
If you have multiple private keys, you can specify which of your private keys to sign the other persons public key with like this:

bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID>
If you have trouble dealing with RSA keys, you're probably using an old version of gnupg. Versions of GnuPG older that 1.0.3 do not include RSA support. Note: You may have to uninstall an older version if your distribution installed it with package management software. You can check the version you're executing like this:

bash$ gpg --version
Step 4: Return or Upload the signed key

If you are working with an entity which does not want their key on a public keyserver, you should at this point you should return their signed key back to them by their method of choice - normally encrypted email. You should not send a public key to a keyserver with out the permission of the key's owner. Publicizing a public key slightly reduces the security of a key pair, therefor it is considered rude to make a key more public than its owner desires.

Most likely you are working with a keyserver. If that is the case, you can send the signed key back to the keyserver like this:

bash$ gpg --keyserver <keyserver> --send-key <Key_ID>
You should see a success message like this:

gpg: success sending to `<keyserver>' (status=200)
Congratulations, the signature of the other entity's key is now complete and your signature has been incorporated into their public key. A trust path has been established.

  • No labels