The private half of the key is stored in an encrypted form, so that anyone
who can read your keystore cannot extract your private key and use it.
You must provide a passphrase for your key when it is generated, which is used
to determine the encryption key. In the future you will need to enter this
passphrase again each time you sign a certificate, which happens every
time you commit to your database. You can tell monotone to
automatically use a certain passphrase for a given key using the
get_passphrase(
key_identity)
, but this significantly
increases the risk of a key compromise on your local computer. Be
careful using this hook.
The public key is stored in the database; the public and private keys are stored in the keystore. This allows copying the database without copying the private key.
The location of the keystore is specified by the --keydir
option; it defaults to the value stored in _MTN/options for
commands executed in a workspace, or to
the system default (~/.monotone/keys on Unix and Cygwin,
%APPDATA%/monotone/keys on native Win32).
get_revision_cert_trust
(see Hook Reference). You pass it
a revision ID, a certificate name, a certificate value, and one or more
key IDs or key names, and it will tell you whether, under your current settings,
Monotone would trust a cert on that revision with that value signed by
those keys.
The specified keys mist exist either in your keystore or in the database.
This command is mainly for use in a session script as monotone will automatically add your keys to ssh-agent on first use if it is available. For example the following two examples are equivalent:
$ mtn ssh_agent_add enter passphrase for key ID [user@example.com]: $ mtn ci -m"Changed foo to bar" $ mtn push -k user@example.com
$ mtn ci -m"Changed foo to bar" enter passphrase for key ID [user@example.com]: $ mtn push -k user@example.com
In the second example, monotone automatically added the key to ssh-agent, making
entering the passphrase not needed during the push.
$ mtn ssh_agent_export ~/.ssh/id_monotone enter passphrase for key ID [user@example.com] (1234abcd...): enter new passphrase for key ID [user@example.com] (1234abcd...): confirm passphrase for key ID [user@example.com] (1234abcd...): $ chmod 600 ~/.ssh/id_monotone $ ssh-agent /bin/bash $ ssh-add ~/.ssh/id_monotone Enter passphrase for /home/user/.ssh/id_monotone: Identity added: /home/user/.ssh/id_monotone (/home/user/.ssh/id_monotone) $ mtn ci -m"Changed foo to bar" $ mtn push -k user@example.com
You can also use the --ssh-sign option to control whether ssh-agent will be used for signing. If set to yes, ssh-agent will be used to sign. If your key has not been added to ssh-agent monotone will fall back to its internal signing code and ask you for your password. If set to only, monotone will sign only with ssh-agent. If set to no, monotone will always use its internal signing code even if ssh-agent is running and has your monotone key loaded. If set to check, monotone will sign with both ssh-agent (if your key is loaded into it) and monotone's internal signing code, then compare the results. check will be removed at some future time as it is meant only for testing and will not work with all signing algorithms.