40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
Currently the assistant sets up a shared encryption key, which is checked
|
|
into git, so anyone who gets the repository can decrypt files that are
|
|
stored encrypted on special remotes.
|
|
|
|
To support using gpg keys in the assistant, we need some things:
|
|
|
|
1. Help user set up a gpg key if they don't have one. This could be a
|
|
special-purpose key dedicated to being used by git-annex. It might be
|
|
nice to leave the user with a securely set up general purpose key,
|
|
but that would certainly preclude prompting for its password in the
|
|
webapp. Indeed, the password prompt is the main problem here.
|
|
Best solution would be to get gpg agent working on all supported
|
|
platforms.
|
|
|
|
Update: For now, git-annex only assists in generating gpg keys that are
|
|
intended to only be used to encrypt a repo.
|
|
|
|
2. After generating a gpg key, back it up. It might be the only way
|
|
some data is accessible.
|
|
|
|
One way I'm considering is generating a QR code
|
|
of the key, which could be printed to paper. Preliminary results
|
|
are good; a 4096 bit secret key fits in a QR code (a secret key
|
|
with many subkeys may not). Debian has command-line utilities that
|
|
can generate and read such a QR code.
|
|
|
|
Another way would be to use shamir secret sharing to split the key into
|
|
N peices and send each one to one of the user's repos.
|
|
|
|
3. Help user learn the gpg keys of people they want to share their repo
|
|
with, and give them access. If the public key was recorded in the git-annex
|
|
branch, this could be easily determined when sharing repositories with
|
|
friends. Or, use MonkeySphere, or Monkeysign..
|
|
|
|
-----
|
|
|
|
Another gpg key security thing is that currently git-annex stores
|
|
crypto creds in memory while it's running. Should use locked memory. See
|
|
<https://github.com/vincenthz/hs-securemem> and
|
|
<https://github.com/vincenthz/hs-securemem/issues/1>
|