mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

reworded encryption stuff on man page, hopefully clearer and less jargon

Browse source
This commit is contained in:
Joey Hess 2013-09-04 18:39:41 -04:00
parent 6f531d903d
commit b17defd43a
1 changed files with 29 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

54
doc/git-annex.mdwn
View file

@ -307,16 +307,20 @@ subdirectories).
types of special remotes need different configuration values. The types of special remotes need different configuration values. The
command will prompt for parameters as needed. command will prompt for parameters as needed.
All special remotes support encryption. You must either specify All special remotes support encryption. You can either specify
encryption=none to disable encryption, or encryption=shared to use a `encryption=none` to disable encryption, or specify
shared cipher (stored clear in the git repository), or `encryption=hybrid keyid=$keyid ...` to specify a gpg key id (or an email
encryption=hybrid to encrypt the cipher to an OpenPGP key, or address accociated with a key.
encryption=pubkey to encrypt file contents using public-key
cryptography. In the two last cases, you also need to specify which There are actually three schemes that can be used for management of the
key can access the encrypted special remote, which is done by encryption keys. When using the encryption=hybrid scheme, additional
specifiying keyid= (gpg needs to be to be able to find a public key gpg keys can be given access to the encrypted special remote easily
matching that specification, which can be an OpenPGP key ID or an (without re-encrypting everything). When using encryption=shared,
e-mail address for instance). a shared key is generated and stored in the git repository, allowing
anyone who can clone the git repository to access it. Finally, when using
encryption=pubkey, content in the special remote is directly encrypted
to the specified gpg keys, and additional ones cannot easily be given
access.
Note that with encryption enabled, a cryptographic key is created. Note that with encryption enabled, a cryptographic key is created.
This requires sufficient entropy. If initremote seems to hang or take This requires sufficient entropy. If initremote seems to hang or take
@ -342,28 +346,28 @@ subdirectories).
For example, the directory special remote requires a directory= parameter. For example, the directory special remote requires a directory= parameter.
This command can also be used to modify the configuration of an existing This command can also be used to modify the configuration of an existing
special remote, by specifying new values for parameters that were originally special remote, by specifying new values for parameters that were
set when using initremote. With the exception of some configuration values such originally set when using initremote. (However, some settings such as
as the encryption scheme scheme, which cannot be changed once the the as the encryption scheme cannot be changed once a special remote
remote has been created. has been created.)
If encryption is enabled and the remote's access limited to one or The gpg keys that an encrypted special remote is encrypted to can be
more OpenPGP key(s), it is possible to give access to another key ID changed using the keyid+= and keyid-= parameters. These respectively
by specifing the keyid+= parameter. While a key can later be removed add and remove keys from the list. However, note that removing a key
from the list, it is to be noted that it does NOT necessarily prevent does NOT necessarily prevent the key's owner from accessing data
the owner of the private material from accessing data on the remote in the encrypted special remote
(which is by design impossible, short of deleting the remote); (which is by design impossible, short of deleting the remote).
however, a fine use-case of keyid-= is to replace a revoked key by
a new one superseeding it: One use-case of keyid-= is to replace a revoked key with
a new key:
git annex enableremote mys3 keyid-=revokedkey keyid+=newkey git annex enableremote mys3 keyid-=revokedkey keyid+=newkey
Also, note that for encrypted special remotes using strict public-key Also, note that for encrypted special remotes using plain public-key
encryption (encryption=pubkey), adding or removing a key has NO effect encryption (encryption=pubkey), adding or removing a key has NO effect
on files that have already been copied to the remote. Hence using on files that have already been copied to the remote. Hence using
keyid+= and keyid-= with such remotes should be used with care, and keyid+= and keyid-= with such remotes should be used with care, and
make little sense unless the private material of the old and new make little sense except in cases like the revoked key example above.
access list is all owned by the same (group of) person.
* trust [repository ...] * trust [repository ...]