Using tufup on Linux

[kubapilch]

When using tufup on Linux, everything works until the installation step of a patch. Is there any reason why it has not been implemented? If there are no limitations, I would try to implement it myself

[dennisvang]

-- edit --

Clarification: The tufup repository tools (server side) fully support Linux, out-of-the-box. The client side does not, but can be customized to do so, as explained below.

-- original --

@kubapilch A Linux install script is not supplied out-of-the-box, because, personally, I believe native packaging solutions are more appropriate on Linux. Think of e.g. apt (deb), flatpak, or snapcraft. A very interesting overview of options can be found in python packaging docs, here.

Nevertheless, it should be relatively easy to write your own install_update function for Linux, using the default install_update script as an example.

You can then pass this custom function into Client.download_and_apply_update() via the install argument. For example:

def install_update_linux(src_dir, dst_dir, purge_dst_dir=False, exclude_from_purge=None, **kwargs):
    # Linux-specific installation steps
    ...

...
client.download_and_apply_update(install=install_update_linux)
...

[kubapilch]

@dennisvang That is exactly what I am doing right now. Should I create a pull request containing the code after I make sure it works as intended, or you do not want to include Linux installation?

[dennisvang]

@kubapilch I'm certainly interested in seeing your solution, so if you could post a snippet here, that would be great.

A pull request is also possible, but that would mean a bit more work for you, and I cannot guarantee a PR would be merged, because I'm still a bit hesitant in adding client-side support for linux, for the reasons mentioned above.

In any case, your code would serve as a useful example for others.

Just out of curiosity: Is there a specific reason you're choosing the tufup approach instead of creating e.g. a deb package, or snapcraft package, or something similar?

[kubapilch]

@dennisvang I will create a pull request after I fully integrate it into my production workflow and have more spare time.

We decided to go with tufup because it is very simple to use and we are very happy with all the benefits it brings with TUF framework

I have one question that I do not want to start a new issue for, I cannot find any information on it online. Let's say that we keep the same expiration dates as the example dummy-app and we regularly re-sign them with tofup CLI tool. What if one of our client devices doesn't connect to the internet for a year or is inactive for some time and is unable to refresh the metadata for so long that all the keys have changed. Will it be able to still refresh the metadata for a new one after a year, or does it need to have for example at least the root key still active to do so.

[dennisvang]

Thanks @kubapilch.

... What if one of our client devices doesn't connect to the internet for a year or is inactive for some time and is unable to refresh the metadata for so long that all the keys have changed. Will it be able to still refresh the metadata for a new one after a year, or does it need to have for example at least the root key still active to do so.

As long as you serve all the intermediate root metadata files, it should still be possible for the client to update properly. tufup uses python-tuf under the hood, which takes care of this automatically.

Here are some relevant parts of the client workflow, from the TUF specification (section 5.2):

... Note that the expiration of the trusted root metadata file does not matter, because we will attempt to update it in the next step.

and from section 5.3:

Since it may now be signed using entirely different keys, the client MUST somehow be able to establish a trusted line of continuity to the latest set of keys (see § 6.1 Key management and migration). To do so, the client MUST download intermediate root metadata files, until the latest available one is reached.

So, every time you update the root metadata, make sure you also keep the old version of that file as well, and serve all versions of the root metadata. For example, root.json, 1.root.json, 2.root.json, ...

[OverDriveGain]

Can you share your code for installing on linux?

[dennisvang]

@OverDriveGain Unfortunately I do not have any tested code available for installing on Linux.

However, I suspect the _install_update_mac() function comes close to what it would look like on Linux. In any case, this would be a good starting point for creating a custom Linux install function.

You can then use your custom install function as explained above.

Perhaps @kubapilch would still be willing to share their solution?

[kubapilch]

We are using a slightly modified version of def _install_update_mac(). In our case it is not meant to be used by a general user but our own machines so sharing our implementation will not be that helpful.

@dennisvang I do not know if you want to keep this issue open or not but as far as I am concerned it can be closed, we resolved all the issues.

[OverDriveGain]

Thanks for all your responses.

I will try then to modify the function _install_update_mac and use it for my usecase. If it was a generic implementation I can try to share the code somewhere in a fork, or here if you guys are interested

[Slarag]

I'm deploying an app for multiple platforms (Windows and Linux). I'm currently evaluating update methods and for consistency I would like to use the same method for both platforms. Hence, Linux support for the client would be great.

[dennisvang]

@Slarag Thanks for taking an interest in tufup. :-)

As noted above, you can create a copy of tufup.utils.platform_specific._install_update_mac() and customize it to suit your needs (if necessary). It might even work without customization, I haven't tried it yet.

Then you can pass the customized function into Client.download_and_apply_update(), as mentioned here.

The tufup Client needs to know where your app is installed, and where to put metadata and temporary update files, see e.g. how the Client is instantiated in the tufup-example app. As a developer you are free too choose these file locations, but different platforms do have different conventions.

The settings for the tufup-example app show one possible way to set up these paths for Windows and macOS. For guidance on Linux, you could have a look at the FHS (Filesystem Hierarchy Standard).

Related: dennisvang/tufup-example#6 (comment)