Changes between Version 11 and Version 12 of UsingPidginMonotone

Timestamp:

Jan 21, 2007, 8:20:38 PM (17 years ago)

Author:

elb

Comment:

Some more text on key management

UsingPidginMonotone

@@ -28 +28 @@
 Consult the monotone documents, and particularly [http://venge.net/monotone/docs/CVS-Phrasebook.html#CVS-Phrasebook their CVS phrasebook] to see the things you can now do with your database and working copy.  You should find that most of the actions at this point feel pretty familiar.
 
-At some point you will probably try to execute a command which requires a keypair.  To generate a keypair, use {{{mtn genkey $KEYID}}}.  Key IDs are normally email addresses, and at this point there is no way to use two keys with the same key ID on the same project (keys are addressed by their ID, not fingerprint etc.)  For playing, you might want to generate a throwaway key ID just in case; I recommend that if we adopt monotone, all developers use a key of the form {{{username@pidgin.im}}} for normal development.  There is nothing which says this must be the case, however, and there is certainly something to be said for using a different key for each physical workstation or administrative domain that one uses.
+== Keys and Key Management ==
+
+Monotone uses asymmetric keypairs for various trust and identification tasks.  Every certificate created by a developer is signed by a keypair unique to that developer.  In practice, this means that every commit to a branch is signed by the developer which made the commit (because the piece of data tying a particular revision to a branch is a certificate).
+
+Therefore, in order to commit revisions, push a revision to most netsync servers, create a certificate, or perform a number of other activities, you will have to have a monotone keypair.  To generate a keypair, use {{{mtn genkey $KEYID}}}.  Key IDs are normally email addresses, and at this point there is no way to use two keys with the same key ID on the same project (keys are addressed by their ID, not fingerprint etc.).  For playing, you might want to generate a throwaway key ID just in case; I recommend that developers' normal pidgin keys be of the form {{{username@pidgin.im}}}.  There is nothing which says this must be the case, however, and there is certainly something to be said for using a different key for each physical workstation or administrative domain that one uses.
+
+Once you have created a key, you can generate a public key which can be shared with other developers (for the purpose of establishing trust, giving netsync permission, etc.) with the command {{{mtn pubkey $KEYID}}}.  The output of this command can be imported into a monotone database with {{{mtn read < $FILE}}}, and then synced to a remote server (even if it has not been used to sign any certificates) with {{{mtn push --key-to-push $KEYID}}}.  Note that if a key has been used to sign certificates which are communicated in a netsync transaction, it will be automatically synced along with the revisions; this means that if third-party developers use monotone (which we should encourage!) and we retrieve changes from them via mtn pull, their keys will be automatically installed in the pidgin.im repository at the next developer push of those revisions.
 
 == Branching {{{im.pidgin.gaim}}} ==