341269e035
* assistant, watcher: .gitignore files and other git ignores are now
honored, when git 1.8.4 or newer is installed.
(Thanks, Adam Spiers, for getting the necessary support into git for this.)
* importfeed: Ignores transient problems with feeds. Only exits nonzero
when a feed has repeatedly had a problems for at least 1 day.
* importfeed: Fix handling of dots in extensions.
* Windows: Added support for encrypted special remotes.
* Windows: Fixed permissions problem that prevented removing files
from directory special remote. Directory special remotes now fully usable.
# imported from the archive
24 lines
1.2 KiB
Markdown
24 lines
1.2 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 two 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 certianly 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.
|
|
2. 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..
|
|
|
|
-----
|
|
|
|
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>
|