Clarification on tuf regarding repo and versioning

35 views
Skip to first unread message

Daniel Kaleja

unread,
Dec 7, 2020, 8:49:25 AM12/7/20
to The Update Framework (TUF)
Hi there again,
I just have one or two major issue on my list that I cannot finally answer. 
1. As far as I understand, tuf follows the one repo for all approach, right? So If I have like 1000+ components I'd like to share and update, the repository files would increase in size and would put additional afford on my clients to process all available files and their states in the repo (kind of like a p2-repo). The only thing I could do is create 1000+ tuf repos... Am I right?
2. Additionally I could not find any information about versioning of files and the tuf repo itself. So is it the plan of tuf to just have always the latest version of anything available in the repo? 
3. Tuf is not solving the issue if the given files actually match to the device requesting an update, right? So If the device requests for some package, it already has to know if the requested package is suitable and can be consumed. 

Best regards

Lukas Puehringer

unread,
Dec 7, 2020, 9:36:32 AM12/7/20
to theupdate...@googlegroups.com
Excellent questions! Let me try to answer them inline...

On 07.12.2020 2:49 PM, 'Daniel Kaleja' via The Update Framework (TUF) wrote:
> Hi there again,
> I just have one or two major issue on my list that I cannot finally answer.
> 1. As far as I understand, tuf follows the one repo for all approach,
> right? So If I have like 1000+ components I'd like to share and update, the
> repository files would increase in size and would put additional afford on
> my clients to process all available files and their states in the repo
> (kind of like a p2-repo). The only thing I could do is create 1000+ tuf
> repos... Am I right?

The answer to this question might be "targets delegation". In a huge repository
with many target files (i.e. the components you want to share and update) it is
not feasible to list all of them (or rather their names, lengths and hashes) in
a single targets metadata file, instead you will distribute them over multiple
delegated targets metadata files. PyPI [1] for instance uses "hash bin
delegation", where each delegated targets metadata file is responsible for a
subset of targets identified by their hashes.

[1] https://www.python.org/dev/peps/pep-0458/

> 2. Additionally I could not find any information about versioning of files
> and the tuf repo itself. So is it the plan of tuf to just have always the
> latest version of anything available in the repo?

Good observation. Although TUF uses version numbers for its own metadata to
guarantee that clients have a fresh view of the target files it serves, it is
not concerned with any versioning of the target files themselves.

That means that it is up to the repo maintainer what files they want to serve.
It could be the latest version, but more likely it will be multiple versions of
a given target file.


> 3. Tuf is not solving the issue if the given files actually match to the
> device requesting an update, right? So If the device requests for some
> package, it already has to know if the requested package is suitable and
> can be consumed.

True. Just like with versions, TUF is oblivious to whether a file is actually
usable by the client.

However, tuf targets metadata has an optional "custom" field for each target
file, which, as per the spec, may contain "version numbers, dependencies,
requirements, or any other data that the application wants to include to
describe the [target] file".

>
> Best regards
>

Kind regards,
Lukas

--
lukas.pu...@nyu.edu
PGP fingerprint: 8BA6 9B87 D43B E294 F23E 8120 89A2 AD3C 07D9 62E8

OpenPGP_signature

Marina Moore

unread,
Dec 7, 2020, 12:03:24 PM12/7/20
to Lukas Puehringer, The Update Framework (TUF)
A small addition to Lukas's answer for number 3:

In a variant of TUF for automobiles (Uptane), a repository 'directs' updates to a vehicle which are installed using TUF, this allows for more control by the repository, and less work for embedded components on the vehicle. There are more details about this approach in the Uptane Standard (https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#directing-installation-of-images-on-vehicles).

--
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 on the web visit https://groups.google.com/d/msgid/theupdateframework/41790382-d01f-6280-c1c2-593f5fe9dfec%40nyu.edu.
Reply all
Reply to author
Forward
0 new messages