mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

strong verification on retrieval from annexobjects location

Browse source 
The file in the annexobjects location may have been renamed from a
previously exported file that got deleted in a subsequent export.
Or it may be renamed to annexobjects temporarily before being renamed to
another name (to handle eg pairwise renames).

But, an exported file is not guaranteed to contain the content of the
key that the local repository last exported there. Another tree could
have been exported from elsewhere in the meantime.

So, files in annexobjects do not necessarily have the content of their
key. And so have to be strongly verified when retrieving. The same as
is done when retrieving exported files.
This commit is contained in:
Joey Hess 2024-08-04 11:17:42 -04:00
parent fe01a1e7e1
commit ee076b68f5
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 29 additions and 31 deletions
Download patch file Download diff file Expand all files Collapse all files

17
doc/todo/exporttree_remotes_could_store_any_key.mdwn
View file

@ -80,8 +80,6 @@ also remove from the objects location.
----
# trust
Could a remote with annexobjects=yet and exporttree=yes but without
importtree=yes not be forced to be untrusted?
@ -92,11 +90,12 @@ If the annexobjects directory only gets keys uploaded to it, and never had
exported files renamed into it, its content will always be as expected, and
perhaps the remote does not need to be untrusted.
OTOH, if an exported file that is being deleted in an updated export gets
renamed into the annexobjects directory, it's possible that the file has in
fact been overwritten with other content (by git-annex in another clone of
the repository), and so the object in annexobjects would not be as
expected. So unfortunately, it seems that rename can't be done.
OTOH, if an exported file that is being deleted (or pairwise renamed) in an
updated export gets renamed into the annexobjects directory, it's possible
that the file has in fact been overwritten with other content (by git-annex
in another clone of the repository), and so the object in annexobjects
would not be as expected. So unfortunately, it seems that rename can't be
done without forcing untrusted.
Note that, exporting a new tree can still delete any file at any time.
If the remote is not untrusted, that could violate numcopies.
@ -114,6 +113,10 @@ the annexobjects directory, and the other for the exported files. This
clean separation avoids the above problem. But would be confusing for the
user. HOWEVER, what if the two were treated as parts of the same cluster....?
This may be worth revisiting later, but for now, I am leaning to keeping it
untrusted, and following down that line to make it as performant as
possible.
---
Implementing in the "exportreeplus" branch --[[Joey]]

7
doc/todo/git-annex_proxies.mdwn
View file

@ -36,13 +36,6 @@ Planned schedule of work:
* `git-annex export` when renaming an exported file to a temporary name
should use the annexobjects location.
* Make annexobjects=true remotes not be untrusted, if possible. See todo.
Alternatively, if they do need to be untrusted, the retrieval from the
annexobjects location may also need to do strong verification of the
content, if exported files ever get renamed into the annexobjects
location.
## items deferred until later for p2p protocol over http
* `git-annex p2phttp` should support serving several repositories at the same