How To Check for Desktop Factory Updates

Overview

This document describes how to check for a newer Factory release, find more information on security related updates, upgrade the Factory, and apply updates. Running "make checkupdates" also lists local updates available in the current Factory version. This happens if your configuration includes any differences from the current Factory defaults (for example, if you upgrade the Factory but have not applied updates). More detail about local updates is available in this document.

Desktop Factory checks with the LinuxLink server to find out if a newer Factory release is available. It will also report specific changes in the latest version that effect selections in your current build configuration. If the updates contain known security fixes for those packages then the related CVE IDs will be listed as well. The update feature requires an active license.

By default, the checkupdates target in Factory now also generates a report about CVEs in the current workorder (in addition to providing information about security fixes in the latest version). See the Factory Security Vulnerability Notification HOWTO for more information.

Checking for Updates

Use the Factory checkupdates make target, which will use your LinuxLink API key to check for a newer Factory version and report any updates specific to your build configuration. If Work Offline is selected in your workorder, this check will be skipped. By default, you will also see the output of checkupdates at the top of every basic Factory build (e.g. when just running "make"). The following is an example of the checkupdates output. It indicates that a new release is available, and some currently selected packages have updates:

$ make checkupdates
-- Checking for updates... -- 1480546051 [Wed, 30 Nov 2016 17:47:31 -0500]

A newer Factory engine (factory-20161122) is available.
It can be downloaded from https://linuxlink.timesys.com/factory/latest

The following updates may be relevant to your current configuration:

Updates to php:
  Bump to version 5.6.26
  Known security fixes: CVE-2016-7416, CVE-2016-7412, CVE-2016-7414, CVE-2016-7417, CVE-2016-7411, CVE-2016-7413, CVE-2016-7418

Updates to tar:
  Patch for CVE-2016-6321
  Known security fixes: CVE-2016-6321

Updates to libpcap:
  Bump to version 1.8.1

If LinuxLink responds with an HTTP 403 error, your API key may not be correct or you may not have an active license.

Upgrading Factory

Using git (recommended)

By cloning the Factory repository from Timesys and maintaining your own branch, you can do powerful things like selectively pull updates, save different versions of your configuration, use tags to track your product history, or just experiment without the risk of losing a working setup.

See these documents for more information on using git with Factory:

• How To Use Git
• How To Clone a Timesys Git Repository
• Upgrading the Factory Build Engine

Download the Latest Factory

A simple alternative is to download the latest factory release and migrate your configuration by following the initial instructions for Upgrading the Factory Build Engine (before the git instructions).

Essentially, you must:

1. extract the new Factory tarball
2. copy the .config file from your existing Factory into the new folder
3. run make olddefconfig in the new Factory folder

TIP: Factory can be easily configured to build up a local cache of source packages, patches, and configuration files used by your Factories so that you can avoid having to re-download them or keep multiple copies. Please see the instructions for using awget here: How do I keep a local repository for my previously chosen packages while still using the Timesys repository for new packages?

Applying updates

Once your Factory is upgraded using either method above, you will have updates to your configuration available. You can selectively accept updates by running "make menuupdate", which is also described in Upgrading the Factory Build Engine.

Extra Information about Security Updates

Updates which fix a security issue with a package may be in one of two forms. One is a new version which includes the fixes, and the other is a set of patches to the current software version. This may be important because in the patch case, you can modify the package's patch list to choose only certain fixes depending on your requirements, but a new version always contains all of the reported fixes.

If an update mentions fixing one or more CVEs then you can learn more about the vulnerabilities by looking up the ID from either MITRE or the NIST National Vulnerability Database. The packages themselves may have information as well. It can often be found in a CHANGELOG or NEWS file inside of the source package, or on its website. The URL for a package can be found from Factory by running "make <package name>-show". The LinuxLink web build configuration tool also links to packages.

Version updates

If the update is a new version of a package, accepting that update will take care of integrating the security fixes. You can't selectively choose what CVEs to fix in this case, as they are integrated into the software update itself. Most packages are fixed this way.

Software patches

If new patches were added to a package, menuupdate will show an update available for "patches". In this interface, you can only accept the new patch list or keep the old one. If you want all patches, then you can just accept the update here.

However, if you decide to apply only some changes, you will need to modify the patch list yourself. You can either accept the new patch list and then remove unwanted patches, or note the new patches and add them to the list. There are a couple of ways to check the patch list changes:

• In menuupdate, view the patch list change by highlighting the "patches" update in the submenu under the package name, and then tabbing over to the <Help> action (or press 'H')
• If using git, review the commit which changed the packages Config.in file for the "TSWO_<pkgname>_PATCHES" change

To edit the patch list for a package:

• In menuconfig, navigate to the package and edit the patch list to add or remove the relevant patch names
• Or directly edit your Factory Workorder (.config file in the top level Factory directory) to change the package patches variable, e.g. "TSWO_busybox_PATCHES".

NOTE: Patch order often matters. By removing some patches from the known-good configuration tested by Timesys, we can not guarantee that they will apply cleanly as-is.

Rebuilding After Updating

If you apply updates or change the patch lists for packages in a Factory which has already been built, you can make sure a package is rebuilt by executing "make <pkg>-distclean" before your next "make." If many things change, or there were base / toolchain updates, you can also just "make clean" and then do a full rebuild with "make."