summaryrefslogtreecommitdiff
path: root/Git/GCrypt.hs
Commit message (Collapse)AuthorAge
* better probing for gcrypt repositories using new --check optionGravatar Joey Hess2013-09-19
| | | | | | | | Now can tell if a repo uses gcrypt or not, and whether it's decryptable with the current gpg keys. This closes the hole that undecryptable gcrypt repos could have before been combined into the repo in encrypted mode.
* webapp: support adding existing gcrypt special remotes from removable drivesGravatar Joey Hess2013-09-18
| | | | | | | | | | | | | | | | | | | | | | | When adding a removable drive, it's now detected if the drive contains a gcrypt special remote, and that's all handled nicely. This includes fetching the git-annex branch from the gcrypt repo in order to find out how to set up the special remote. Note that gcrypt repos that are not git-annex special remotes are not supported. It will attempt to detect such a gcrypt repo and refuse to use it. (But this is hard to do any may fail; see https://github.com/blake2-ppc/git-remote-gcrypt/issues/6) The problem with supporting regular gcrypt repos is that we don't know what the gcrypt.participants setting is intended to be for the repo. So even if we can decrypt it, if we push changes to it they might not be visible to other participants. Anyway, encrypted sneakernet (or mailnet) is now fully possible with the git-annex assistant! Assuming that the gpg key distribution is handled somehow, which the assistant doesn't yet help with. This commit was sponsored by Navishkar Rao.
* gcrypt: Ensure that signing key is set to one of the participants keys.Gravatar Joey Hess2013-09-17
| | | | | | Otherwise gcrypt will fail to pull, since it requires this to be the case. This needs a patched gcrypt, which is in my forked version.
* partially complete gcrypt remote (local send done; rest not)Gravatar Joey Hess2013-09-07
| | | | | | | | | | | | | | | | | | | | | | | | This is a git-remote-gcrypt encrypted special remote. Only sending files in to the remote works, and only for local repositories. Most of the work so far has involved making initremote work. A particular problem is that remote setup in this case needs to generate its own uuid, derivied from the gcrypt-id. That required some larger changes in the code to support. For ssh remotes, this will probably just reuse Remote.Rsync's code, so should be easy enough. And for downloading from a web remote, I will need to factor out the part of Remote.Git that does that. One particular thing that will need work is supporting hot-swapping a local gcrypt remote. I think it needs to store the gcrypt-id in the git config of the local remote, so that it can check it every time, and compare with the cached annex-uuid for the remote. If there is a mismatch, it can change both the cached annex-uuid and the gcrypt-id. That should work, and I laid some groundwork for it by already reading the remote's config when it's local. (Also needed for other reasons.) This commit was sponsored by Daniel Callahan.
* add getParticipantListGravatar Joey Hess2013-09-05
| | | | | Note that it needs to look at global git config, since git-remote-gcrypt will see any setting there as a fallback.
* automatically derive an annex-uuid from a gcrypt-uuidsGravatar Joey Hess2013-09-05