[RFC,v2] pkcs11-provider: import version 1.3.0 from meta-oe

OpenSSL 4.x removed the ENGINE API. Add pkcs11-provider to OE-Core
to support token-backed keys for target applications and native signing
tools without requiring meta-oe. Token drivers and provider activation
remain product-specific.

Imported from meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb

Signed-off-by: Ayoub Zaki <ayoub.zaki@embetrix.com>
---
 meta/conf/distro/include/maintainers.inc      |  1 +
 .../pkcs11-provider/pkcs11-provider_1.3.0.bb  | 21 +++++++++++++++++++
 2 files changed, 22 insertions(+)
 create mode 100644 meta/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb

Hi,


On 10/28/26 10:32, Ayoub Zaki wrote:
> OpenSSL 4.x removed the ENGINE API. Add pkcs11-provider to OE-Core
> to support token-backed keys for target applications and native signing
> tools without requiring meta-oe. Token drivers and provider activation
> remain product-specific.
> 
> Imported from meta-oe/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb
> 
> Signed-off-by: Ayoub Zaki <ayoub.zaki@embetrix.com>
> ---
>   meta/conf/distro/include/maintainers.inc      |  1 +
>   .../pkcs11-provider/pkcs11-provider_1.3.0.bb  | 21 +++++++++++++++++++
>   2 files changed, 22 insertions(+)
>   create mode 100644 meta/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb
> 
> diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
> index 74db3e44e9..10cf20a885 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -604,6 +604,7 @@ RECIPE_MAINTAINER:pn-piglit = "Ross Burton <ross.burton@arm.com>"
>   RECIPE_MAINTAINER:pn-pigz = "Kris Gavvala <kris.gavvala@windriver.com>"
>   RECIPE_MAINTAINER:pn-pinentry = "Unassigned <unassigned@yoctoproject.org>"
>   RECIPE_MAINTAINER:pn-pixman = "Unassigned <unassigned@yoctoproject.org>"
> +RECIPE_MAINTAINER:pn-pkcs11-provider = "Unassigned <unassigned@yoctoproject.org>"
>   RECIPE_MAINTAINER:pn-pkgconf = "Ross Burton <ross.burton@arm.com>"
>   RECIPE_MAINTAINER:pn-pm-utils = "Ross Burton <ross.burton@arm.com>"
>   RECIPE_MAINTAINER:pn-pointercal-xinput = "Unassigned <unassigned@yoctoproject.org>"
> diff --git a/meta/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb b/meta/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb
> new file mode 100644
> index 0000000000..bd51625b8e
> --- /dev/null
> +++ b/meta/recipes-support/pkcs11-provider/pkcs11-provider_1.3.0.bb
> @@ -0,0 +1,21 @@
> +SUMMARY = "An OpenSSL provider for accessing PKCS#11 tokens"
> +DESCRIPTION = "An OpenSSL provider to access hardware or software tokens through \
> +the PKCS#11 Cryptographic Token Interface."
> +HOMEPAGE = "https://github.com/openssl-projects/pkcs11-provider"
> +BUGTRACKER = "https://github.com/openssl-projects/pkcs11-provider/issues"
> +SECTION = "libs"
> +LICENSE = "Apache-2.0"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=b53b787444a60266932bd270d1cf2d45"
> +
> +DEPENDS = "openssl p11-kit"
> +
> +SRC_URI = "git://github.com/openssl-projects/${BPN}.git;branch=main;protocol=https;tag=v${PV}"
> +SRCREV = "b55b94344af87a058fd84d6e15390760a5585b1d"
> +
> +CVE_PRODUCT = "latchset:pkcs11-provider"
> +
> +inherit meson pkgconfig
> +
> +FILES:${PN} += "${libdir}/ossl-modules/pkcs11.so"
> +
> +BBCLASSEXTEND = "native"

The integration report this error:


https://bodnuti.dev/reports/openembedded-core/20261028093240.345039-1-ayoub.zaki@embetrix.com/

Is this a known limitation of the checker when introducing a new recipe 
or is there something I should consider?

What is the recommended way to handle this?


Kind regards

On Wed, 28 Oct 2026 at 10:49, Ayoub Zaki via lists.openembedded.org
<ayoub.zaki=embetrix.com@lists.openembedded.org> wrote:

> OpenSSL 4.x removed the ENGINE API. Add pkcs11-provider to OE-Core
> to support token-backed keys for target applications and native signing
> tools without requiring meta-oe. Token drivers and provider activation
> remain product-specific.
>

I would note that meta-oe contains a signing.bbclass, which presumably
offers a better more and standard way to handle signing in Yocto than just
setting custom, recipe- (or layer-) specific variables in local.conf, and
generating disk keys with custom shell scripts.

If you want to add a recipe to oe-core, you need have consumers for the
recipe, or explain how is it supposed to be used.  Let's say I built this
recipe, what then?

Should we import the signing class as well?  Maybe we need softhsm in
oe-core too? Should we have tests and documentation for all of this? I lean
towards yes, because secure boot is becoming increasingly important, and
yocto's support for it is fragmented and vendor-specific, but doing this
right does require quite a bit more work than just copying the recipe from
one layer into another.

In other words, the justification should be more than just "I don't want
meta-oe in dependencies".

Alex

On Wed, 28 Oct 2026 at 16:05, Ayoub Zaki via lists.openembedded.org
<ayoub.zaki=embetrix.com@lists.openembedded.org> wrote:

> The integration report this error:
>
>
>
> https://bodnuti.dev/reports/openembedded-core/20261028093240.345039-1-ayoub.zaki@embetrix.com/
>
> Is this a known limitation of the checker when introducing a new recipe
> or is there something I should consider?
>
> What is the recommended way to handle this?
>

The oelint checker is not a part of the yocto or openembedded projects, and
its output is not considered when reviewing patches. You need to take this
to oelint maintainers or support channels.

Alex

Hi,


On 10/28/26 16:46, Alexander Kanavin wrote:
> On Wed, 28 Oct 2026 at 10:49, Ayoub Zaki via lists.openembedded.org 
> <http://lists.openembedded.org> 
> <ayoub.zaki=embetrix.com@lists.openembedded.org 
> <mailto:embetrix.com@lists.openembedded.org>> wrote:
> 
>     OpenSSL 4.x removed the ENGINE API. Add pkcs11-provider to OE-Core
>     to support token-backed keys for target applications and native signing
>     tools without requiring meta-oe. Token drivers and provider activation
>     remain product-specific.
> 
> 
> I would note that meta-oe contains a signing.bbclass, which presumably 
> offers a better more and standard way to handle signing in Yocto than 
> just setting custom, recipe- (or layer-) specific variables in 
> local.conf, and generating disk keys with custom shell scripts.
> 
> If you want to add a recipe to oe-core, you need have consumers for the 
> recipe, or explain how is it supposed to be used.  Let's say I built 
> this recipe, what then?

The primary motivation is OpenSSL 4 removing the ENGINE API rather than 
avoiding a meta-oe dependency!

PKCS#11-backed signing now needs the provider-based integration.
There is already a concrete consumer in OE-Core:

U-Boot’s OpenSSL fit signing Provider API patch:

https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-bsp/u-boot/files/0001-Add-support-for-OpenSSL-Provider-API.patch



> 
> Should we import the signing class as well?  Maybe we need softhsm in 
> oe-core too? Should we have tests and documentation for all of this? I 
> lean towards yes, because secure boot is becoming increasingly 
> important, and yocto's support for it is fragmented and vendor-specific, 
> but doing this right does require quite a bit more work than just 
> copying the recipe from one layer into another.
> 

that would be a nice addition later on.

> In other words, the justification should be more than just "I don't want 
> meta-oe in dependencies".

and this recipe supplies a missing component


Mit freundlichen Grüßen / Kind regards

On Wed, 28 Oct 2026 at 16:58, Ayoub Zaki <ayoub.zaki@embetrix.com> wrote:

>
> The primary motivation is OpenSSL 4 removing the ENGINE API rather than
> avoiding a meta-oe dependency!
>
> PKCS#11-backed signing now needs the provider-based integration.
> There is already a concrete consumer in OE-Core:
>
> U-Boot’s OpenSSL fit signing Provider API patch:
>
>
> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-bsp/u-boot/files/0001-Add-support-for-OpenSSL-Provider-API.patch


This patch  was added to u-boot recipe, so that it would build without
errors with openssl 4.x as a part of an update patchset to that openssl
version. That doesn't mean that the function was tested, or that oe-core is
expected to support the use case. There's lots of oe-core components that
load plugins at runtime, that doesn't mean oe-core should provide recipes
for them all.

If you want this in core, you need to show how the ecosystem would benefit
from the move. There's lots of meta-oe recipes that could be moved to core
(actually all of them), what makes this one special? What layers are using
it, and do not already require meta-oe? If it is added, how can someone
confirm that it works, using only oe-core?

Alex