63 lines
3.5 KiB
Markdown
63 lines
3.5 KiB
Markdown
Started work on [gcrypt](https://github.com/blake2-ppc/git-remote-gcrypt)
|
|
support.
|
|
|
|
The first question is, should git-annex leave it up to gcrypt to transport
|
|
the data to the encrypted repository on a push/pull? gcrypt hooks into git
|
|
nicely to make that just work. However, if I go this route, it limits
|
|
the places the encrypted git repositores can be stored to regular git
|
|
remotes (and rsync). The alternative is to somehow use gcrypt to
|
|
generate/consume the data, but use the git-annex special remotes to store
|
|
individual files. Which would allow for a git repo stored on S3, etc.
|
|
For now, I am going with the simple option, but I have not ruled out
|
|
trying to make the latter work. It seems it would need changes to gcrypt
|
|
though.
|
|
|
|
Next question: Given a remote that uses gcrypt, how do I determine the
|
|
annex.uuid of that repository. I found a nice solutuon to this. gcrypt has
|
|
its own gcrypt-id, and I convert it to a UUID in a
|
|
[[reproducible, and even standards-compliant way|design/gcrypt]]. So
|
|
the same encrypted remote will automatically get the same annex.uuid
|
|
wherever it's used. Nice. Does mean that git-annex cannot find a uuid
|
|
until `git pull` or `git push` has been used, to let gcrypt get the
|
|
gcrypt-id. Implemented that.
|
|
|
|
The next step is actually making git-annex store data on gcrypt remotes.
|
|
And it needs to store it encrypted of course. It seems best to avoid
|
|
needing a `git annex initremote` for these gcrypt remotes, and just have
|
|
git-annex automatically encrypt data stored on them. But I don't
|
|
know. Without initializing them like a special remote is, I'm limited to
|
|
using the gpg keys that gcrypt is configured to encrypt to, and cannot use
|
|
the regular git-annex hybrid encryption scheme. Also, I need to generate
|
|
and store a nonce anyway to HMAC ecrypt keys. (Or modify gcrypt
|
|
to put enough entropy in gcrypt-id that I can use it?)
|
|
|
|
Another concern I have is that gcrypt's own encryption scheme is simply
|
|
to use a list of public keys to encrypt to. It would be nicer if the
|
|
full set of git-annex encryption schemes could be used. Then the webapp
|
|
could use shared encryption to avoid needing to make the user set up a gpg
|
|
key, or hybrid encryption could be used to add keys later, etc.
|
|
|
|
But I see why gcrypt works the way it does. Otherwise, you can't make an
|
|
encrypted repo with a friend set as one of the particpants and have them be
|
|
able to git clone it. Both hybrid and shared encryption store a secret
|
|
inside the repo, which is not accessible if it's encrypted using that
|
|
secret. There are use cases where not being able to blindly clone a gcrypt
|
|
repo would be ok. For example, you use the assistant to pair with a friend
|
|
and then set up an encrypted repo in the cloud for both of you to use.
|
|
|
|
Anyway, for now, I will need to deal with
|
|
setting up gpg keys etc in the assistant. I don't want to tackle
|
|
full [[design/assistant/gpgkeys]] yet. Instead, I think I will start by
|
|
adding some simple stuff to the assistant:
|
|
|
|
* When adding a USB drive, offer to encrypt the repository on the drive
|
|
so that only you can see it.
|
|
* When adding a ssh remote make a similar offer.
|
|
* Add a UI to add an arbitrary git remote with encryption.
|
|
Let the user paste in the url to an empty remote they have,
|
|
which could be to eg github. (In most cases this won't be used for
|
|
annexed content..)
|
|
* When the user has no gpg key, prompt to set one up. (Securely!)
|
|
* Maybe have an interface to add another gpg key that can access the gcrypt
|
|
repo. Note that this will need to re-encrypt and re-push the whole
|
|
git history.
|