Ordering of Software Sources
As was explained in the Device Security Policy section of Security Aspects of SW Distribution and Application Installation, the Device security policy contains a list of known software sources and maintains their ordering. In fact software sources are arranged in a software source tree, where each node represents a software source and position of a node in a tree defines a trust level of a software source. Arranging software sources in a tree structure allows to simplify the management of software source configurations and provision of keys. This means that parent software sources can configure their sub-sources without a need to contact one central distributor. More information about how to configure software sources can be found in Configuring Device Security Policy and Software Sources.
For example, let's consider a software source tree, shown on the figure 1. It has six software sources defined, node "Root" is a root of the tree, nodes "Tizen.org", "T-developers.org" and "Unknown" are children of "Root" node, and nodes "testing" and "stable" are children of "T-developers.org" node. The "T-developers.org" software source can define a needed amount of its sub-sources, and in this example, it defined two: "stable" for providing application packages that has been released and "testing" for providing application packages that are still in a beta quality. The "T-developers.org" can independently provision the keys for its sub-sources, as well as delete its sub-sources or add new sub-sources without having a need to do it via the "Root" software source.
Figure 1. Example of software source tree
The software source tree building happens in the following way. The first software source is defined during the image building phase and it becomes the root of the tree. The definition of software source is done by installing an empty package with a special manifest file, where software source name is defined together with its public key. After, sub-nodes of the root node (and subsequently any sub-nodes) can be defined by installing similar packages with software source definitions that have to be signed with a secret key that corresponds to a provided public key for a parent software source.
Using the software tree above, the building of a tree will be happening as follows. Fist a package that defines "Root" software source is installed that provides a public key for this software source. Then, a package that defines a software source "Unknown" can be installed, that is signed with the secret key of "Root" software source. Then, similarly packages that define software sources "Tizen.org" and "T-developers.org" are installed and they are also signed with the secret key of "Root" software source. Then the packages that define "stable" and "testing" software sources are installed, and they are signed with a secret key of "T-developers.org" software source. The order of package installation here is given just for illustrative purpose and can be changed without affecting the tree structure, because the structure formed based on package signature and not on the order of installation. Only the "Root" software source must be installed first.
When a new software source defined, together with its name and associated public key, a relative trust level is also defined. Relative trust level represents the ordering of software sources related to its parent. For example, for the tree above, the relative trust levels for the "Root" software source children can be defined as shown on the figure 2. Higher number represents lower trust level. By default, the parent software source has a relative trust level of "0" and therefore more trusted compare to any of its children that have relative trust levels higher than one.
Figure 2. Relative trust levels of "Root" software source children.
Figure 3 shows an example of relative trust levels defined for children of "T-developers.org" software source. Logically, the sub-source "stable" is more trusted than sub-source "testing" since it contains already well-tested and stable application packages.
Figure 3. Relative trust levels of "T-developers.org" software source children.
Relative trust levels are used to build absolute trust levels (later just trust levels) that would regulate an update rule for the Tizen platform. The trust levels are build based on the software source tree and defined relative trust levels in the following way. The highest trust level is given to a root of the tree, and then the child that has the lowest relative trust level is assigned a next trust level. If this child doesn't have any children, then the next child of a root node that has the lowest relative trust level is given a next trust level. If the child has children, then the next trust level is assigned to its child that has the lowest relative trust level and etc. For the example of the tree above, the result trust levels are shown on the figure 4. These trust levels define the update rule for packages for given software source tree: a package update can be installed only from the software source with the same trust level or higher.
Figure 4. Trust levels of software source tree.