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:
parent
0815c82bb1
commit
ecc8162203
6 changed files with 75 additions and 6 deletions
|
@ -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..
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue