diff --git a/doc/todo/exporttree_remotes_could_store_any_key.mdwn b/doc/todo/exporttree_remotes_could_store_any_key.mdwn index 2184123e02..7ae5bf2346 100644 --- a/doc/todo/exporttree_remotes_could_store_any_key.mdwn +++ b/doc/todo/exporttree_remotes_could_store_any_key.mdwn @@ -117,3 +117,5 @@ possible. --- Implementing in the "exportreeplus" branch --[[Joey]] + +> [[done]] --[[Joey]] diff --git a/doc/todo/git-annex_proxies.mdwn b/doc/todo/git-annex_proxies.mdwn index eef29fa1e0..082bbe0eac 100644 --- a/doc/todo/git-annex_proxies.mdwn +++ b/doc/todo/git-annex_proxies.mdwn @@ -35,6 +35,35 @@ Planned schedule of work: * A proxied exporttree=yes special remote is not untrusted, and should be. + This needs Remote.untrustworthy to be set when constucting a proxied + Remote that uses exporttree=yes. So will need to load the remote config + to see if it does. + + But, the proxy.log uses the UUID of a remote. There could be multiple + special remotes that share a UUID. Which config to load? Maybe load the + configs of them all and check if any has exporttree=yes. + Probably all ought to if any do. + + Alternatively, make annexobjects=yes remotes not untrusted. + This was considered in [[todo/exporttree_remotes_could_store_any_key]], + but didn't seem very feasible. + +* Also, versioned exports are not untrustworthy. But checking that would + need to construct a Remote using the special remote's config. + + For eg S3 (the only versioned one currently), that would need the S3 + creds to be set in the environment. + + For an external special remote that uses the (currently draft) extension, + the program would need to be installed to check how it responds to + VERSIONED. + + Constructing a special remote in order to use it proxied does not seem + feasible. + + versionedExport could be changed be a pure function from + ParsedRemoteConfig. But that would not help with external special remotes. + ## completed items for August * Special remotes configured with exporttree=yes annexobjects=yes