stdenv: Add CPE fields to meta

Add `identifiers` attr to `meta` attribute with following attrs:
* `cpe` with the full CPE string when available
* `possibleCPEs` with the list of potential CPEs when not all
  information is provided
* `cpeParts` with the destructured CPE string, allowing to override it
  whenever needed
* `v1` attribute set with `cpe` and `cpeParts` from above and a
  guarantee of a backwards-compatible interface

Related issue: https://github.com/NixOS/nixpkgs/issues/354012
This commit is contained in:
Yuriy Taraday
2025-05-20 17:04:01 +02:00
parent b5d48d2918
commit b0ce3dc09f
11 changed files with 364 additions and 1 deletions

View File

@@ -248,3 +248,74 @@ Code to be executed on a peripheral device or embedded controller, built by a th
### `lib.sourceTypes.binaryBytecode` {#lib.sourceTypes.binaryBytecode}
Code to run on a VM interpreter or JIT compiled into bytecode by a third party. This includes packages which download Java `.jar` files from another source.
## Software identifiers {#sec-meta-identifiers}
Package's `meta.identifiers` attribute specifies information about software identifiers associated with this package. Software identifiers are used, for example:
* to generate Software Bill of Materials (SBOM) that lists all components used to build the software, which can later be used to perform vulnerability or license analysis of the resulting software;
* to lookup software in different vulnerability databases or report new vulnerabilities to them.
Overriding the default `meta.identifiers` attribute is optional, but it is recommended to fill in pieces to help tools mentioned above get precise data.
For example, we could get automatic notifications about potential vulnerabilities for users in the future.
All identifiers specified in `meta.identifiers` are expected to be unambiguous and valid.
`meta.identifiers` contains `v1` attribute which is an attribute set that guarantees backward compatibility of its constituents. Right now it contains copies of all other attributes in `meta.identifiers`.
### CPE {#sec-meta-identifiers-cpe}
Common Platform Enumeration (CPE) is a specification maintained by NIST as part of the Security Content Automation Protocol (SCAP). It is used to identify software in National Vulnerabilities Database (NVD, https://nvd.nist.gov) and other vulnerability databases.
Current version of CPE 2.3 consists of 13 parts:
```
cpe:2.3:a:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>
```
Some of them are as follows:
* *CPE version* - current version of CPE is `2.3`
* *part* - usually in Nixpkgs `a` for "application", can also be `o` for "operating system" or `h` for "hardware"
* *vendor* - can point to the source of the package, or to Nixpkgs itself
* *product* - name of the package
* *version* - version of the package
* *update* - name of the latest update, can be a patch version for semantically versioned packages
* *edition* - any additional specification about the version
You can find information about all of these attributes in the [official specification](https://csrc.nist.gov/projects/security-content-automation-protocol/specifications/cpe/naming) (heading 5.3.3, pages 11-13).
Any fields that don't have a value are set to either `-` if the value is not available or `*` when the field can match any value.
For example, for glibc 2.40.1 CPE would be `cpe:2.3:a:gnu:glibc:2.40:1:*:*:*:*:*:*`.
#### `meta.identifiers.cpeParts` {#var-meta-identifiers-cpeParts}
This attribute contains an attribute set of all parts of the CPE for this package. Most of the parts default to `*` (match any value), with some exceptions:
* `part` defaults to `a` (application), can also be set to `o` for operating systems, for example, Linux kernel, or to `h` for hardware
* `vendor` cannot be deduced from other sources, so it must be specified by the package author
* `product` defaults to provided derivation's `pname` attribute and must be provided explicitly if `pname` is missing
* `version` and `update` have no defaults and should be specified explicitly or using helper functions, when missing, `cpe` attribute will be empty, and all possible guesses using helper functions will be in `possibleCPEs` attribute.
It is up to the package author to make sure all parts are correct and match expected values in [NVD dictionary](https://nvd.nist.gov/products/cpe). Unknown values can be skipped, which would leave them with the default value of `*`.
Following functions help with filling out `version` and `update` fields:
* [`lib.meta.cpeFullVersionWithVendor`](#function-library-lib.meta.cpeFullVersionWithVendor)
* [`lib.meta.cpePatchVersionInUpdateWithVendor`](#function-library-lib.meta.cpePatchVersionInUpdateWithVendor)
For many packages to make CPE available it should be enough to specify only:
```nix
{
# ...
meta.identifiers.cpeParts = lib.meta.cpePatchVersionInUpdateWithVendor vendor version;
}
```
#### `meta.identifiers.cpe` {#var-meta-identifiers-cpe}
A readonly attribute that concatenates all CPE parts in one string.
#### `meta.identifiers.possibleCPEs` {#var-meta-identifiers-possibleCPEs}
A readonly attribute containing the list of guesses for what CPE for this package can look like. It includes all variants of version handling mentioned above. Each item is an attrset with attributes `cpeParts` and `cpe` for each guess.