Client update failing due root metadata version

[Milan Satpathy]

Hi,

I recently created a new repository and added a target file to it. However, when I tried to run the client to download the target file, 

I encountered the following error:

File "/home/msatpathy/.local/lib/python3.8/site-packages/tuf/ngclient/updater.py", line 143, in refresh  
    self._load_root()  
File "/home/msatpathy/.local/lib/python3.8/site-packages/tuf/ngclient/updater.py", line 334, in _load_root  
    self._trusted_set.update_root(data)  
File "/home/msatpathy/.local/lib/python3.8/site-packages/tuf/ngclient/_internal/trusted_metadata_set.py", line 187, in update_root  
    raise exceptions.BadVersionNumberError(  
tuf.api.exceptions.BadVersionNumberError: Expected root version 2 instead got version 1  

When creating the repository, I set the "persistent snapshot" option to false. Unless the root metadata has expired or a key rotation is required, 

I don't see why the root version needs to be incremented.

I would like to understand why the client should fail abruptly when it doesn't find the next version of root metadata during each refresh.

(I have gone through https://theupdateframework.github.io/specification/latest/#detailed-client-workflow , yet this behavior seems unexpected)

Could anyone please guide me on how to resolve this issue?

Thanks in advance !

Best Regards,

Milan Satpathy

[Jussi Kukkonen]

Hi,

First, it's definitely possible we haven't tested non-consistent snapshot as well as most parts of python-tuf...

• I would strongly advice using consistent snapshot -- I think there is no reason to avoid it and that the only reason we have not removed support for non-consistent snapshot is the fact that python-tuf is a reference implementation and we did not want to do it while non-persistent snapshots are part of the spec... 
• Still, python-tuf claiming to support something and then being buggy is the worst option. bug reports (https://github.com/theupdateframework/python-tuf/issues/new) or patches are welcome

That said, I don't think root update process changes based on consistent snapshot: The error implies that

• client had root v1 at this point
• client asked repository for "2.root.json" as spec requires
• repository replied with metadata that contains version 1

this seems like it would be a spec violation from the repository whether consistent snapshot is used or not -- or maybe I don't quite understand the situation?

Best,
Jussi

--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/theupdateframework/CAOjUHMxAB9dvXLvSEM60CVK2PP8e1LPf%3DsNbSjHtM3n5TpVfDA%40mail.gmail.com.

[Jussi Kukkonen]

Missed this:

> I would like to understand why the client should fail abruptly when it doesn't find the next version of root metadata during each refresh

The python-tuf client does not fail if root version N+1 is not found on remote repository: at this point root version N is considered the valid root (assuming it passes other validity checks like not being expired) and the update process continues to timestamp and onwards.

Trying to download root N+1 is required by the spec. Spec does not define how a HTTP repository states that "root version is not found" but python-tuf and other clients assume that it responds with 404 in that case.