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
