Package com.kosdev.kos.commons.manifest.chained

Class ChainedManifest

java.lang.Object
com.kosdev.kos.commons.manifest.DeviceManifestVersion
com.kosdev.kos.commons.manifest.install.InstallManifest
com.kosdev.kos.commons.manifest.chained.ChainedManifest
public class ChainedManifest extends InstallManifest
A ChainedManifest defines a collection of sections that contains artifacts that are used to resolve external references from a NodeManifest. This allows for the creation of device manifests that can be augmented in controlled ways by chained manifests which can be generated by other organizations. Since the device manifest can never be modified by other organizations as there would be no way to sign it with the correct authority, this mechanism provides supply chain security and also ensures that upstream organizations cannot modify any device manifest in ways not defined by the originating organization.

Every ChainedManifest contains a name. This must be unique within the chain and the name must be well known so that a node manifest can reference it by its name.

Since the ChainedManifest is delivered as a KAB, the manifest has an associated authority established by the keys used to sign the manifest. Consumers of this manifest must specify the authority in order to use it. This ensures that other organizations can't supply a chained manifest with the same name and override the resolution process.

Each section defined in the manifest is identified by a name and contains a list of artifacts. When referenced by a node manifest using ChainedSectionRef, the name is matched using the srcSection property. When the section is placed in the node manfiest it will appear with the dstSection name. This allows upstream systems to build common manifests that can be used across many devices as the device developer can map section names as needed within their references.

A ChainedManifest contains a collection of properties. These are not used by KOS, but are available for tooling to inject data for upstream use. For example, in a system where multiple chained manifests are built by different systems, upstream systems may not have access to the original device manifest. Intermediate tooling can pass data from the original manifest to upstream processes, or provide information about the chained manifest itself to the next upstream process without needing to pass additional out of band data.

Api version 10 introduced the concept of reverse manifest linking. While a typical chain builds manifests one at a time, passing the id of the previous manifest to the next in order to create the chain, this has a side effect of forcing upstream manifests to be rebuilt any time an earlier manifest changes due to the need to include the id of the previously generated manifest to link them. Reverse linking allows upstream manifests to be created without populating the nextManifestId property as the reverse linked manifest will include all upstream manifest id's in the new reverseLinkedManifestIds list. This requires that all upstream manifests be created first so the id's can be identified for inclusion in the reverse linked manifest. Practically speaking, this allows a single aggregator to query multiple external systems for manifests and add them to a single reverse linked manifest which is then chained normally to the device manifest. This can drastically reduce the creation of unique manifest kabs.

To use reverse linked manifests, the manifests being reverse linked to must have nextManifestId set to null.

Since:
1
Version:
10