VURL verifyKeyContent True when there are no recorded equivkeys

Avoid verification error when addurl --verifiable is used with an url
claimed by a special remote other than the web.
This commit is contained in:
Joey Hess 2025-01-03 17:24:30 -04:00
parent 0815c82bb1
commit ecc8162203
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 75 additions and 6 deletions

View file

@ -1,3 +1,5 @@
[[!meta title="VURL equivilant keys not populated when addurl is used with special remotes other than web"]]
### Please describe the problem.
With an external special remote that handles a custom URL scheme, I receive a "Verification of content failed" on the first `git annex get` of a file (i.e. when git-annex cannot know a checksum for the file, yet).

View file

@ -0,0 +1,49 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2025-01-03T19:52:28Z"
content="""
Looking at [[!commit 55bf01b78888b410a8ac07e834ed7104ffa1f4d0]] it talks
about something like this:
When downloading a VURL from the web, make sure that the equivilant key
log is populated.
...
Downloads of VURL keys from other special remotes that claim urls,
like bittorrent for example, does not popilate the equivilant key log.
So for now, no checksum verification will be done for those.
I think at the time, I just punted on the question of how to register the
equivilant key when downloading a VURL from other special remotes.
Thing is, git-annex just calls retrieveKeyFile at some point. At that
point, it doesn't know if it's retrieving the key from the web or some
other special remote that claims urls.
It would not do for a `git-annex get` that happens to get the VURL key from
eg, a directory special remote to say hey, we've not populated the
equivilant key log for this VURL yet, let's trust what we downloaded from
the remote is good and populate it now.
So that's why the code went into the web special remote. It seems to me that to
move it out of the web special remote, there would need to be a way for
git-annex to check if a given special remote claims the url associated with a
VURL. Eg, look up the key's url(s) and check claimUrl.
Hmm, if it did that, there would still be a problem that retrieveKeyFile can
try to verify the content it downloads, using verifyKeyContent. But when no
equivilant key is yet registered for the VURL, retrieveKeyFile would find that
anything it downloaded failed to verify. So it would fail. Chicken and egg problem.
But well, it would be easy enough to make this not be treated as a failure.
In Backend.VURL, verifyKeyContent returns False when there are no equivilant
keys. It could just return true.
That seems like a necessary first step. Just making that change will solve your
problem to the extent that it's ok for no verification of the content of VURLs
to be done when they originate with your special remote.
So I've done that. Whether it makes sense to do the rest I am not yet sure..
"""]]