reopen
This commit is contained in:
parent
7f356edc46
commit
e6fdd01f6e
2 changed files with 35 additions and 3 deletions
|
@ -1,6 +1,14 @@
|
||||||
### Feature request
|
### Feature request
|
||||||
It is not possible to put encrypted content in place on remotes with just a public GPG key. You always need the private key, even for encryption. I guess this is because how the cipher HMAC is used for replacing file names with their hashes. However, if that requirement (having secret file names) was dropped, I assume a pubkey-only mode could be implemented?
|
|
||||||
|
|
||||||
My specific use case is backup archiving. I have my backups packed in archive files and want to use git-annex to copy the archives to offsite remotes (S3). In that case, I don't care much about hiding file names, but would appreciate the increased security of not having the secret key on the backup server. It would only be needed if I wanted to verify or restore backups.
|
It is not possible to put encrypted content in place on remotes with just a
|
||||||
|
public GPG key. You always need the private key, even for encryption. I
|
||||||
|
guess this is because how the cipher HMAC is used for replacing file names
|
||||||
|
with their hashes. However, if that requirement (having secret file names)
|
||||||
|
was dropped, I assume a pubkey-only mode could be implemented?
|
||||||
|
|
||||||
> [[closed|done]] per my comment --[[Joey]]
|
My specific use case is backup archiving. I have my backups packed in
|
||||||
|
archive files and want to use git-annex to copy the archives to offsite
|
||||||
|
remotes (S3). In that case, I don't care much about hiding file names, but
|
||||||
|
would appreciate the increased security of not having the secret key on the
|
||||||
|
backup server. It would only be needed if I wanted to verify or restore
|
||||||
|
backups.
|
||||||
|
|
|
@ -0,0 +1,24 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 3"""
|
||||||
|
date="2015-04-06T17:04:34Z"
|
||||||
|
content="""
|
||||||
|
I somehow completely misread what you wanted! Thanks, it makes sense now.
|
||||||
|
|
||||||
|
I anticipate there would be one problem with this mode; `git annex fsck --from remote`
|
||||||
|
would fail because it would be unable to decrypt the encrypted content
|
||||||
|
when run on the client that is only able to encrypt to the public key, but
|
||||||
|
lacks the necessary private key to decrypt.
|
||||||
|
|
||||||
|
(So would `git annex move --to remote; git annex get --from remote`, but
|
||||||
|
presumably that failure is the point of the mode..)
|
||||||
|
|
||||||
|
It would be fairly easy to add this, I think. There is already support
|
||||||
|
for configuring the MAC algorithm to use to encrypt filenames. Your mode seems
|
||||||
|
to just need a "clear" mode that doesn't encrypt filenames at all.
|
||||||
|
|
||||||
|
It does add complication to crypto paths, and potential for user
|
||||||
|
foot-shooting though.
|
||||||
|
|
||||||
|
I'm going to move this feature request from bugs/ to todo/
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue