NSLU2-Linux
view · edit · print · history

HowTo.CreateAndUseMonotoneKeys History

Hide minor edits - Show changes to markup

January 03, 2007, at 07:26 AM by simon --
Changed lines 5-6 from:

Chosing a monotone ID

to:

Choosing a monotone ID

August 27, 2005, at 02:26 PM by peteru -- Update key names to reflect current convention.
Changed lines 9-12 from:

For this reason you must chose an ID which no one else could chose. To make this possible nslu2-linux and openembedded developers (and quite probably all monotone users) follow the simple convention of using an email address as the ID. The easiest way is to use your own normal email address, however it is also reasonable to use any address at a domain which you control.

In addition you should chose an ID which can be related to the identifier you use on development related IRC channels (for example #nslu2-linux) and the nslu2-linux and OpenEmbedded (handhelds.org) mailing lists. If you don't do this and you later want to contribute changes to the nslu2-linux development you will probably be asked to chose a different ID. This is so that other developers can immediately identify who made a particular change!

to:

The convention used for openembedded development is to choose a key of the form userid@openembedded.org

You should chose an ID which can be related to the identifier you use on development related IRC channels (for example #nslu2-linux) and the nslu2-linux and OpenEmbedded (handhelds.org) mailing lists. If you don't do this and you later want to contribute changes to the nslu2-linux development you will probably be asked to chose a different ID. This is so that other developers can immediately identify who made a particular change!

Changed lines 17-18 from:
monotone genkey you@domain.whatever
to:
monotone genkey userid@openembedded.org
Changed lines 23-25 from:
monotone pubkey you@domain.whatever >~/mykey.txt
monotone privkey you@domain.whatever >>~/mykey.txt
to:
monotone pubkey userid@openembedded.org >~/mykey.txt
monotone privkey userid@openembedded.org >>~/mykey.txt
August 01, 2005, at 10:46 PM by jbowler --
Changed lines 21-22 from:

Once you have created the key you must ensure that the private part never gets lost. Write the key to a reliable hard copy medium. For example:

to:

Once you have created the key you must ensure that the private part never gets lost. Write the key to a reliable hard copy medium and store it somewhere where simultaneous damage to both it and your file systems is very unlikely. For example:

August 01, 2005, at 10:43 PM by jbowler -- Added more advice
Changed lines 7-8 from:

The monotone key is, itself, your monotone identity, but when monotone uses the key it refers to it using a textual ID. Every ID in the database must be unique - therefore every key has to have a unique ID. What is more the IDs? are not local to the database - if your changes ever get pushed into remote databases the public part of your key and your chosen ID will go with the changes.

to:

The monotone key is, itself, your monotone identity, but when monotone uses the key it refers to it using a textual ID. Every ID in the database must be unique - therefore every key has to have a unique ID. What is more the ID is not local to the database - if your changes ever get pushed into remote databases the public part of your key and your chosen ID will go with the changes.

Added lines 10-32:

In addition you should chose an ID which can be related to the identifier you use on development related IRC channels (for example #nslu2-linux) and the nslu2-linux and OpenEmbedded (handhelds.org) mailing lists. If you don't do this and you later want to contribute changes to the nslu2-linux development you will probably be asked to chose a different ID. This is so that other developers can immediately identify who made a particular change!

Creating the monotone key

Once you have chosen your ID use the monotone command to generate a new key:

monotone genkey you@domain.whatever

This places both the public and private part of the key into your database - if you are not in a monotone working directory you will need to give the --db option too.

Once you have created the key you must ensure that the private part never gets lost. Write the key to a reliable hard copy medium. For example:

monotone pubkey you@domain.whatever >~/mykey.txt
monotone privkey you@domain.whatever >>~/mykey.txt

Then print out mykey.txt, copy it to a CD-R, write it into a flash memory device and store all three in secure bank vaults in separate banks.

This may seem a little anal-retentive, however, if you lose the private key you can never regenerate it (i.e. it is computationally impossible for you to recover it from the public key) and three things will happen:

  1. You will be unable to commit any more changes with the corresponding public key (because you don't have the private key to generate the correct certificates).
  2. You will be forced to generate a new ID - because even though you have lost the private key the public key is still in existence and cannot be removed once it is associated with a change in the database. Thus you cannot re-use the old ID.
  3. You will be taunted, at least once and probably a second time.
August 01, 2005, at 10:27 PM by jbowler -- Page about monotone keys, in preparation
Added lines 1-10:

If you start to modify parts of the OpenEmbedded build (for the Unslung firmware and any part of OpenSlug or UcSlugC) you will eventually want to save your changes.

You can use your local monotone database to do this - you don't have to have write access to the nslu2-linux or OpenEmbedded databases to save changes locally. To write to the database, however, you must generate a key, and when you do so it is very important that you do not lose the private part of the key.

Chosing a monotone ID

The monotone key is, itself, your monotone identity, but when monotone uses the key it refers to it using a textual ID. Every ID in the database must be unique - therefore every key has to have a unique ID. What is more the IDs? are not local to the database - if your changes ever get pushed into remote databases the public part of your key and your chosen ID will go with the changes.

For this reason you must chose an ID which no one else could chose. To make this possible nslu2-linux and openembedded developers (and quite probably all monotone users) follow the simple convention of using an email address as the ID. The easiest way is to use your own normal email address, however it is also reasonable to use any address at a domain which you control.

view · edit · print · history · Last edited by simon.
Based on work by peteru and jbowler.
Originally by jbowler.
Page last modified on January 03, 2007, at 07:26 AM