update

doc/todo/exporttree_remotes_could_store_any_key.mdwn

@@ -117,3 +117,5 @@ possible.
 ---
 
 Implementing in the "exportreeplus" branch --[[Joey]]
+
+> [[done]] --[[Joey]]

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