Unit Category
The units of a p2 repository or an Eclipse product installation are categorized according to the following classifiers.
Binary
- A binary unit is a component of type library. It is generally a zip file whose content is processed by so-called touchpoints to provision artifacts into an installation. For example, it can contain a native executable that will be assigned the appropriate POSIX permissions when placed at its intended destination.
Bundle
- A bundle unit is a component of type library. It is a jar representing an OSGi bundle. The jar may be unpacked when provisioned into an installation.
Feature
- A feature unit is a component of type library. It is a jar representing an Eclipse feature, which is effectively a collection of dependencies on other bundles and features that should be installed together to provide some logically cohesive functionality. The jar may be unpacked when provisioned into an installation.
Metadata
-
A metadata unit is a component of type data.
It is a logical component for which no corresponding physical artifact exists.
It exists only in a p2 metadata repository or in an installation profile,
which is also logically a metadata p2 repository.
It specifies dependencies on other components
as well as touchpoints describing actions to be applied to artifacts as they are installed.
For example, it may set program arguments or VM arguments in a product's
*.ini
.
Double clicking an item in this row of filters will make it the only check-marked filter except if it's already the only check-marked filter, in which case all filters will be check-marked.
Unit Name
Each component has a name. In terms of p2, this is generally the ID of the unit, which, along with the version, uniquely identifies unit.
The content of the view can be filtered to show only the units matching the specified name.
If the search value starts with a /
,
it will be interpreted as a regular expression.
Otherwise the search value will be interpreted literally.
Use the Enter
key to apply the filter;
clear the field to remove the filter.
Children
Details about each component are available as nested content. This so-call child content can be displayed via the expand / collapse icon to the left of each component. Each type of child content can be individually filtered to reduce the overall information content of the rendered SBOM and to provide an overview of just the child content of interest.
Via the child filters, you can select to show all components, only those components with nested children, or only those components with no children.
You might, for example, filter the child content to show only licenses, and then elect to show only components with no children to get a list of components without licenses.
Package URL
Each component optionally has a PURL, or package-url, that uniquely identifies the component. For the CBI SBOM generator, every component has an associated PURL. This URL generally encodes traceability details about the origin on the component, e.g., the Maven coordinates of an artifact from Maven Central, or the originating p2 URL repository along with sufficient details for locating the component that that repository.
Double clicking this item will make it the only check-marked child filter except if it's already the only check-marked child filter, in which case all child filters will be check-marked.
Pedigree
In some cases a component is known to be derived from another component. The component from which it is derived is recorded as the pedigree, specifically via the pedigree ancestor.
Many artifacts available in Maven Central are not provided in the form of an OSGi bundle,
i.e., do that have the required OSGi metadata in the MANIFEST.MF
that is necessary to function as an OSGi bundle in an OSGi runtime.
Such an artifact can be repackaged using BND instructions to synthesize the necessary OSGi metadata.
The Maven Central artifact PURL of the original component is captured to provide traceability.
The source artifact associated with each Maven Central binary artifact is also generally not in the form of an OSGi bundle.
These are automatically transformed by Tycho to add the necessary OSGI metadata to the MANIFEST.MF
.
In these cases, the Maven Central artifact PURL of the original component is captured in the pedigree to provide traceability details. In general, the CBI SBOM generator will compare the checksums of a Maven Central artifact against the checksums of the local artifact before generating a PURL reference to the Maven Central artifact. When they do not match exactly, the pedigree captures the derivation link.
Hash Sum
Each component optionally has hashes to provide a way to verify that a component's content matches what is expected. The CBI aggregator produces hashes for each component that corresponds to a physical artifact, i.e., each components of type library. The algorithm of the hash is displayed; the content can be displayed by hovering and can copied to the clipboard by clicking on algorithm label.
License
Each component optionally has licenses. Licences are bit of a mess. There are so many different ways and places to specify license details, producing consistent, well-formed, accurate license information is a significant challenge for the CBI SBOM generator. A license name and license URI are recorded on a best-effort basis.
Detail
Each component optionally has supplementary details such as publisher and description. These details are generally available for all bundle and feature components.
Property
Each component optionally has properties, i.e., a series of name-value pairs that capture additional relevant information. In general p2 units have many associated properties, most of which are captured in other aspect of the generated SBOM, and are therefore generally filtered out by the CBI SBOM generator.
The CBI SBOM generator currently attempts to find license information via https://clearlydefined.io
which generally works well only for artifacts from Maven Central.
These are recorded in the property clearly-defined
.
The CBI SBOM generator records touchpoint information as properties.
Touchpoints are relevant from a security point of view because a touchpoint can in principle configure the installation in a way that affects behaviour of the system,
possibly in a way that compromises security.
Of course generally the touchpoints do simple necessary things
like unzipping an artifact,
setting POSIX permissions of a resource,
and setting required program and VM arguments in the product's *.ini
.
These are recorded in the property touchpoint
.
Property Name
External Reference
Each component optionally has external references, i.e., a series of typed URLs that reference external sites of the given type.
The CBI SBOM generator currently attempts to find license information via https://clearlydefined.io
which generally works well only for artifacts from Maven Central.
These are recorded in the property clearly-defined
.
The CBI SBOM generator records touchpoint information as properties.
Touchpoints are relevant from a security point of view because a touchpoint can in principle configure the installation in a way that affects behaviour of the system,
possibly in a way that compromises security.
Of course generally the touchpoints do simple necessary things
like unzipping an artifact,
setting POSIX permissions of a resource,
and setting required program and VM arguments in the product's *.ini
.
These are recorded in the property touchpoint
.
External Reference Type
Dependency: Incoming and Outgoing
An SBOM supports specifying dependencies between components. Directly represented in the SBOM are each component's dependencies on other components. These are the so-called incoming dependencies. The renderer also displays the inverse of this information, i.e., the so-called outgoing dependencies. These dependencies between components are linkified by the render to support navigation in either direction.
SBOM Metadata
The CBI SBOM generator populates the following information for each SBOM:
- The version of the SBOM.
- The format of the SBOM.
- The specification version of the SBOM format.
- The serial number of the SBOM.
Control Area
The control area provides the following support:
- The hide / show icon allows to hide and show the entire filter and control area above to provide more real estate for the content below.
- The reset icon allows to reset all filters and controls above to their default values.
- The Expand All / collapse All icon allows to expand or collapse all the content below.
- The animated busy indicator is displayed while the view contents are being computed.