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
|
||||
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