linux/meta-openembedded.git/meta-oe/classes, branch wrynose

signing.bbclass: add signing_create_uri_pem helper function

2026-03-05T06:26:02+00:00

The PKCS#11 provider has a mechanism [1] to support older applications which have not yet migrated to the OSSL_STORE API [2]. It works by encoding the 'pkcs11:' URI into a PEM file and passing that to an application as a file. From the application's perspective it loads the private key from a file, but OpenSSL will transparently use select the provider to access it via PKCS#11 instead. Instead of upstream's Python-based tool [3] (which would pull in asn1crypto as a dependency), we just generate the ASN.1 for the PEM using OpenSSL's 'asn1parse -genconf'. It has been tested with RAUC, U-Boot's mkimage (for signed FITs) and NXP's CST. [1] https://github.com/latchset/pkcs11-provider/blob/main/docs/provider-pkcs11.7.md#use-in-older-applications-uris-in-pem-files [2] https://docs.openssl.org/master/man7/ossl_store/ [3] https://github.com/latchset/pkcs11-provider/blob/main/tools/uri2pem.py Signed-off-by: Jan Luebbe Signed-off-by: Fabian Pflug Signed-off-by: Khem Raj

signing.bbclass: add support for OpenSSL PKCS#11 provider

2026-03-05T06:26:02+00:00

OpenSSL 4.0 will drop support for engines and use providers instead. To access SoftHSM and other PKCS#11 modules via the provider API, we rely on https://github.com/latchset/pkcs11-provider, which is already available as via pkcs11-provider recipe. We enable this provider by using a specific OpenSSL config when signing. This means that recipes inheriting this class can decide whether they want to use the engine or provider to access the key. SoftHSM seems to produce broken keys when calling the C_CopyObject, so disable caching in the provider for now. Signed-off-by: Jan Luebbe Signed-off-by: Fabian Pflug Signed-off-by: Khem Raj

signing.bbclass: remove trailing white space

2026-03-05T06:26:02+00:00

Signed-off-by: Jan Luebbe Signed-off-by: Khem Raj

meta-oe: image: optionally remove RAW image after sparse image creation

2025-09-15T16:55:16+00:00

When creating sparse images, the RAW image is no longer needed in some workflows such as Android and CI pipelines. These RAW images can be multi-GB artifacts and consume significant disk space. This change introduces a configuration option `DELETE_RAWIMAGE_AFTER_SPARSE_CMD` which, when set to "1", removes the RAW image after sparse image generation. This reduces disk usage in builds where sparse images are the final deliverables and RAW images are not required. Default behavior is unchanged: RAW images are kept unless the variable is explicitly enabled: DELETE_RAWIMAGE_AFTER_SPARSE_CMD = "1" # Delete RAW image DELETE_RAWIMAGE_AFTER_SPARSE_CMD = "0" # Default behavior Signed-off-by: AshishKumar Mishra Signed-off-by: Khem Raj

image_types_verity.bbclass: remove breaking unit suffix from machine-readable verity parameters

2025-09-02T15:57:41+00:00

Since cryptsetup 2.8.0 [1], "veritysetup format" prints " [bytes]" suffixes for "Data block size" and "Hash block size" parameters: UUID: Hash type: 1 Data blocks: 34655 Data block size: 4096 [bytes] Hash blocks: 275 Hash block size: 4096 [bytes] Hash algorithm: sha256 Salt: 8a8d8d807bd9838a80397a13b3bc13c55780ff1677ee4489366b17dab1b29316 Root hash: bd85312151dc5c69efce943038e0ac4b92e14d8954cce5d3cc90513837f854bf This output is directly converted to a shell sourcable form in "${DEPLOY_DIR_IMAGE}/.verity-params" used to create the desired block device via "dmsetup" during runtime. The unit suffix becomes part of the VERITY_DATA_BLOCK_SIZE and VERITY_HASH_BLOCK_SIZE variables, breaking its consumers: /init: /verity-params: line 4: [bytes]: not found /init: /verity-params: line 6: [bytes]: not found verity root hash: bd85312151dc5c69efce943038e0ac4b92e14d8954cce5d3cc90513837f854bf [ 3.323577] device-mapper: table: 253:0: verity: Invalid data device block size (-EINVAL) [ 3.323595] device-mapper: ioctl: error adding target to table [ 3.345301] /dev/dm-0: Can't lookup blockdev Fix this by removing the unit suffixes from the values. Ideally veritysetup should support machine-readable output, but that did not spark joy on the maintainer's side [2] (at least in veritysetup itself). [1] commit f8788f34 ("Mark all sizes in status and dump output in the correct units.") [2] https://gitlab.com/cryptsetup/cryptsetup/-/issues/638 Signed-off-by: Bastian Krause Signed-off-by: Khem Raj

signing.bbclass: create env with 0x600

2025-08-20T14:35:07+00:00

The env file holds the PKCS#11 uris, which include the pin to access the database - in plaintext. Directly create the file (after it has been remove) with the proper 'user RW only' permissions, to give only the build-user access to this somewhat "security sensitive" file. Note that the softhsm/sqlite3.db* is already 0x600. Signed-off-by: Johannes Schneider Signed-off-by: Khem Raj

gitpkgv.bbclass: inspect repository in UNPACKDIR

2025-08-18T14:50:01+00:00

When BB_GIT_SHALLOW = "1" is used, the unpacked gir repository doesn't exist in the download folder, and the class isn't able to inspect the details of the repository. Instead inspect the repository it the UNPACKDIR. Beside this, since BitBake fetcher performs an actual initial shallow clone of the repository when this feature is enabled, it is not possible to determine the exact number of commits. Add a warning about this. Reported-by: WXbet Signed-off-by: Gyorgy Sarvari Signed-off-by: Khem Raj

signing.bbclass: make PEM loading compatible with OpenSC 0.26.0

2025-07-02T16:48:26+00:00

With https://github.com/OpenSC/OpenSC/pull/3174 which is part of 0.26.0, OpenSC does not support reading the (DER-converted) object data from stdin anymore. However, OpenSC/pkcs11-tool also supports reading PEM files directly. This we can use for simply replacing and simplifying the stdin piping in signing_import_cert_from_pem(). Only for password-protected files we still have to use OpenSSL for conversion, since OpenSC/pkcs11-tool currently doesn't have a mechanism for providing passwords. For these cases, we store the converted PEM into a simple temporary file. This handling is sufficient, since SoftHSM import should be used for example keys only and SoftHSM also doesn't protect the keys in any way. Keys which actually need to be protected are stored in HSMs and accessed via their PKCS#11 URIs. Signed-off-by: Enrico Jörns Signed-off-by: Khem Raj

signing.bbclass: remove signing_import_cert_chain_from_pem

2025-06-28T18:04:25+00:00

With the now available set|get|has_ca functions to establish a CA link between roles during their import, the signing_import_cert_chain_from_pem can now be removed. As it had the shortcoming of dynamically creating roles, which are harder to handle then the manually/specifically setup CA roles. This effectively reverts: a825b853634 signing.bbclass: add certificate ca-chain handling Reviewed-by: Jan Luebbe Signed-off-by: Johannes Schneider Signed-off-by: Khem Raj

signing.bbclass: add signing_extract_cert helpers

2025-06-28T18:04:25+00:00

Add extract-cert wrapping helper functions, to easily extract certificates again that had been previously imported into the softhsm. Reviewed-by: Jan Luebbe Signed-off-by: Johannes Schneider Signed-off-by: Khem Raj