update for new rclone gitannex command
authorJoey Hess <joeyh@joeyh.name>
Tue, 26 Mar 2024 17:48:43 +0000 (13:48 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 26 Mar 2024 17:48:43 +0000 (13:48 -0400)
doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment [new file with mode: 0644]
doc/special_remotes/rclone.mdwn
doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn [new file with mode: 0644]

diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment b/doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment
new file mode 100644 (file)
index 0000000..1a4bf82
--- /dev/null
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-03-26T17:38:07Z"
+ content="""
+See [[todo/external_special_remotes_not_using_git-annex-remote_in_name]]
+for possible changes in git-annex related to this.
+"""]]
index 2afbe93899bcf395184bb903f78965c85e7d0dfc..046630445b54bd5be73b4b35959087857db0e703 100644 (file)
@@ -24,7 +24,14 @@ the time of writing, this includes the following services:
   * Yandex Disk
   * The local filesystem
 
-That list is regularly expanding. git-annex supports all of those through
+That list is regularly expanding. 
+
+git-annex supports all of those through
 the use of the [rclone special remote](https://github.com/DanielDent/git-annex-remote-rclone).
 
+Alternatively, rclone recently gained support for being used as a special
+remote on its own, without needing installation of the above program.
+For documentation on using rclone that way, see the output of
+`rclone gitannex` or [here](https://github.com/git-annex-remote-rclone/git-annex-remote-rclone).
+
 See their documentation for more concrete examples.
diff --git a/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn b/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn
new file mode 100644 (file)
index 0000000..5083acc
--- /dev/null
@@ -0,0 +1,29 @@
+rclone now supports being run as a git-annex special remote natively
+see <https://github.com/rclone/rclone/pull/7654>. "rclone gitannex"
+is the command to run. But git-annex needs a git-annex-remote-rclone or similar,
+so they are shipping a git-annex-remote-rclone-builtin symlink to rclone,
+and when run under that name it behaves as if "rclone gitannex" were run.
+
+So in this case, the need for "git-annex-remote-foo" is complicating an
+upstream project that has gone out of its way to support git-annex. Not ideal.
+
+From the pull request, @dmcardle wrote:
+
+> My taste would be to implement a more generic mechanism rather than adding a special case for rclone gitannex. 
+> What if externaltype could be repeated, so that git annex initremote MyRemote type=external externaltype=rclone >
+> externaltype=gitannex ... would cause git-annex to exec rclone with the additional gitannex arg?
+
+But, that seems to present a security problem. Consider an attacker who runs
+`git-annex initremote foo type=external autoenable=true externaltype=rm externaltype=/foo`
+
+My conclusion is that git-annex can't provide a generic way to run a different
+command for an external special remote. Any such commands need to be
+whitelisted in some way. And if they're whitelisted, it seems better to not
+require the user to enter additional parameters at all.
+
+So one way would be to make "git-annex initremote foo type=external externaltype=rclone-builtin"
+run "rclone gitannex".
+
+Or, git-annex add an internal rclone special remote, that is just
+a wrapper around the external special remote, that makes it use
+"rclone gitannex". "git-annex initremote foo type=rclone" --[[Joey]]