Announcing automatically updating Linux LibreOffice builds

I’m finally ready to announce LibreOffice daily builds for Linux that integrate our new automatic updater. The work on the automatic updater has been going on for nearly a year now and is finally in a shape that we produce builds on TDF hardware that will automatically update using delta updates.

The current builds are 64-bit Linux builds created on SLES 12.2 and should run on most Linux distros. These builds are .tar.gz based archives that you can extract and just run. Note that we can’t update builds that are placed into locations that are not writeable by the current user (and due to missing support for signing executables and libraries on Linux there are no plans to change that).

Below you will find a short summary how the updating works and some of my open items until this feature can be shipped in release builds (hopefully already in the next major release). If you are not interested in the technical details, head to the daily builds directory and download the build (currently the only way to see that an update happened is through the version string in About dialog but future builds will open my test wiki page after a successful build).

Technical details

Our updater code is heavily based on the Mozilla updater code and was initially imported into the LibreOffice build system as part of GSoC 2015.

The update files are called mar files and contain bzip2 compressed update files. In addition to the update files (either complete or delta updates) mar files also contain signatures, version info and update channel information. We currently only use the signature support to ensure that the update files are valid LibreOffice update files produced by us and the version info to make sure that nobody can do a downgrade.

The update process is currently a two step process but I might change this to single step process later. The first step currently contacts our update server that knows about all available updater enabled builds and will tell the LibreOffice instance which update files to use and provide some additional information. Based on the response the LibreOffice instance will download the update file, verify that the file is correct (file size and hash), copy the existing installation and apply the update in the update directory. After the update has been applied the first stage is complete and we need to wait until the next start to replace the running LibreOffice instance with the freshly updated one. During the next start the updated build in the update directory replaces the existing installation.

We currently use a two step process to ensure that we are not blocking the user too long as downloading a complete update file can take several minutes (about 200 MB compared to around 2 MB for my current delta files) and ensuring that if one of the steps fails we still have a working build. However, anyone who has ever developed complex code on Windows knows that Windows prohibits access to files that are already open by another process. Therefore this approach does not work on Windows and I think the two step process has some potential for user profile corruption if the user profile is stored in the installation directory (e.g. by default in our archive based builds). The long term plan is currently to switch to an update process that first downloads the update file and during the next start applies the update in-place. This approach would work on Windows and should avoid all potentials for user profile corruptions.

Another huge problem of the automatic updater is how to handle the case that the user can not write to the installation directory (e.g. installed as a normal application on Windows). Mozilla handles this case on Windows through an additional updater service that elevates the privileges of the updater process. Currently my plan is to use the same concept for LibreOffice and the code for the updater service already compiles successfully on Windows. Using such a service requires us to make sure that the service can not be used by any executable that is not produced by the LibreOffice team which requires signatures checks during each step. As I could not find a way to reliably sign executables and libraries on Linux there is currently no supported planned for this feature outside of Windows.

The updater seems to work reliably on Linux already and many of the basic features that I have on my list are already implemented. Currently the one remaining feature that I still need to implement for all platforms is some form of an UI. The larger task is to get the updater working well on Windows, including the updater service and the MSI integration through MSP updates. In addition, I would like to implement some automatic tests that make sure that updates work and that updated builds and freshly installed builds are identical.

If you want to help with the work on improving the automatic updater and making it available in our next major release please talk to me. A good starting point might be tdf#108563, a simple easy hack in the online updater code.

As always I have to thank all developers working on LibreOffice, the TDF infrastructure team which provides all the services that are used to produce the builds and especially the Mozilla team for providing an awesome solution as open source that we can easily integrate.