From: Joey Hess Date: Wed, 18 Sep 2024 13:08:42 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~21^2~32 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=5e51e7c3395d769c7ee70011991947c12df5212e;p=git-annex.git comment --- diff --git a/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_2_6263583bf51e5296926ccc838c63ba97._comment b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_2_6263583bf51e5296926ccc838c63ba97._comment new file mode 100644 index 0000000000..71cca3e6a9 --- /dev/null +++ b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_2_6263583bf51e5296926ccc838c63ba97._comment @@ -0,0 +1,39 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2024-09-18T12:17:02Z" + content=""" +Another place this came up is + +where a proxy to an encrypted special remote necessarily does encryption +server side, but the user may not want the server to see their unencrypted +files. + +There I suggested "adding a special remote that does its own client-side +encryption in front of the proxy". Such a layered special remote could also be +used with a git remote. There would be some complexity cost, since you would +have two remote names, one used for git and the other for git-annex. + +Implementing object encryption in git remotes is certianly possible, but it +would be a special case and the existing code for encrypting special +remotes (particularly Remote.Helper.Special.specialRemote) +would not be able to be reused. + +There's also the problem that, if such a git repository is added as a +regular remote, and the git-annex branch that indicates that it is +encrypted has not yet been pulled, git-annex would not realize that it is +supposed to be encrypted, so would send unencrypted objects to it. This +seems like an easy situation to accidentially get into eg: + + git remote add foo http://example.com/ + git annex move --to foo # oops unencrypted + +Overall I prefer the idea of layering an encrypted special remote to +complicating the git remote with encryption. Enabling that special remote +could make git-annex treat the underlying remote as annex-ignore, to +prevent accidentially sending unencrypted objects to it. + +There could also be situations where you want to store some files unencrypted +on a git hosting site to let them be accessible via its UI, but encrypt other +files, and the layered special remote also allows for that kind of thing. +"""]]