[PATCH v4] Add support for OpenSSL Provider API

[Quentin Schulz]

Hi Eddie,

On 5/20/26 12:28 PM, Quentin Schulz wrote:
> On 4/29/26 8:02 PM, Eddie Kovsky wrote:
[...]>> +    store = OSSL_STORE_open(path, NULL, NULL, NULL, NULL);
>> +    ERR(!store, "OSSL_STORE_open");
>> +
>> +    while (!OSSL_STORE_eof(store)) {
>> +        OSSL_STORE_INFO *info = OSSL_STORE_load(store);
>> +
>> +        if (!info) {
>> +            drain_openssl_errors(__LINE__, 0);
>> +            continue;
>> +        }
>> +        if (OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY) {
>> +            private_key = OSSL_STORE_INFO_get1_PKEY(info);
>> +            ERR(!private_key, "OSSL_STORE_INFO_get1_PKEY");
>> +        }
> 
> I have been told that calling OSSL_STORE_expect() with the expected type 
> should make it easier to get the object we want directly.
> 
> Something like
> 
> OSSL_STORE_expect(store, OSSL_STORE_INFO_PKEY);
> 
> right after OSSL_STORE_open(). I'm assuming this should allow us to get 
> rid of the OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY check 
> since OSS_STORE_load() would only return objects of expected type.
> 
> c.f. https://eur02.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Fdocs.openssl.org%2F3.0%2Fman3%2FOSSL_STORE_expect%2F%23description&data=05%7C02%7Cquentin.schulz%40cherry.de%7C02bd298ec294469f172a08deb65a8a6d%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639148697211162781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v8m2m1Mi5UXizJjVHHUE2EPryifJfMTnDgrSgFZx1b8%3D&reserved=0
> 
> I've not tested this myself yet.
> 

This was actually required for my custom provider. When you don't set 
the expected type, your provider store context's OSSL_STORE_PARAM_EXPECT 
param gets initialized to zero which means "return all supported 
OSSL_STORE_INFO_* objects except for OSSL_STORE_INFO_NAME". Our custom 
provider didn't implement that (it does now) and would simply say that 
what's requested is invalid. I'm unsure whether this means our custom 
provider was broken or if we should cater for this corner case and 
simply request a store its private key?

On a more general topic, I cannot build anything including the 
openssl/engine.h header without openssl-devel-engine on Fedora. This 
means tools/binman/test/fit/dummy-rsa-engine.c but also CST 
(https://gitlab.apertis.org/pkg/imx-code-signing-tool/-/blob/debian/unstable/code/back_end-ssl/src/engine.c?ref_type=heads#L11) 
which means we cannot run the binman test suite on Fedora without 
openssl-devel-engine package installed, or anything that requires CST, 
e.g. the nxp-imx8mcst nodes in binman. I'll try to figure out a way to 
handle the dummy-rsa-engine.c and be able to skip engine/provider tests 
if unsupported.

Someone will need to have a look at adding support for providers to CST. 
We download and build code from apertis.org but I'm unsure whether we're 
really supposed to use that or report bugs there. Debian points to 
https://salsa.debian.org/collabora-team/imx-code-signing-tool instead so 
maybe we should report there? They seem to be an import from NXP, so 
adding Peng in Cc, maybe they know who to ask for provider support (or 
at the very least, remove engine support if engine support is disabled 
in OpenSSL so it can compile just fine).

Cheers,
Quentin