update
authorJoey Hess <joeyh@joeyh.name>
Wed, 13 Mar 2024 15:19:04 +0000 (11:19 -0400)
committerJoey Hess <joeyh@joeyh.name>
Wed, 13 Mar 2024 15:19:04 +0000 (11:19 -0400)
doc/design/balanced_preferred_content.mdwn
doc/design/passthrough_proxy.mdwn

index f46eac84703d9b5ea354d41887cc5d970e04101a..2a84b1273c126b2577768ea67d4f5556b94e40e4 100644 (file)
@@ -140,4 +140,6 @@ would surely have been in vain.)
 
 ## see also
 
-[[todo/proving_preferred_content_behavior]]
+[[todo/proving_preferred_content_behavior]]  
+[[todo/passthrough_proxy]]  
+
index 16b5dc7f0e4682ca6f8e1f1a4511ad6e0486c32a..c5c93851681c96254ba52a3533d268feeb9bbdf6 100644 (file)
@@ -107,3 +107,18 @@ content. Eg, analize what files are typically requested, and store another
 copy of those on the proxy. Perhaps prioritize storing smaller files, where
 latency tends to swamp transfer speed.
 
+## encryption
+
+When the proxy is in front of a special remote that uses encryption, where
+does the encryption happen? It could either happen on the client before
+sending to the proxy, or the proxy could do the encryption since it
+communicates with the special remote. For security, doing the encryption on
+the client seems like the best choice by far.
+
+But, git-annex's git remotes don't currently ever do encryption. And
+special remotes don't communicate via the P2P protocol with a git remote.
+So none of git-annex existing remote implementations would be able to handle
+this case. So something will need to be changed in the remote
+implementation to handle this case.
+
+(Chunking has the same problem.)