I spent some time with OpenSSL 3.0 so I could help.   In generall, all EC_KEY and RSA_KEY functions are deprecated for public use as this is a low-level API. There is no easy fix though-- the low-level functions need to be replaced by the high-level EVP API and there is no simple 1:1 mapping. The affected functions need to be rewritten almost completely, but in case of tpm2-tools and tpm2-pkcs11 the impact is not so high.   The good thing is that the EVP API is not(!) new. It has been there since OpenSSL 1.1.0, so one could write an implementation that works with both OpenSSL 1.1.x and OpenSSL 3.0. In fact, the OpenSSL 3.0 aims to have a very limited impact on "well-behaved" applications that refrain from using the (now deprecated) low-level APIs. An app that uses the EVP API from 1.1.x shall work with the 3.0 too.     The crucial question is: is it acceptable to require the OpenSSL 1.1.1 as the minimum version for tpm2-tools and tpm2-pkcs11?   The OpenSSL release strategy indicates the OpenSSL 1.1.1 is now the _only_ supported version! The 1.0.2 is no longer supported and also the 1.1.0 is no longer supported. https://www.openssl.org/policies/releasestrat.html   Maintaining the support for the EOL OpenSSL (prior 1.1.1) would make the support for OpenSSL 3.0 more complicated, harder to review and maintain. Even the tpm2-tools RELEASE.md says that "supporting an EOL crypto library is not a good idea". https://github.com/tpm2-software/tpm2-tools/blob/master/doc/RELEASE.md#op...     So, my recommendation would be to set OpenSSL 1.1.1 as the minimum version and then simply rewrite the affected functions using the EVP API from 1.1.1, which works also in 3.0. What do you think?     Regards, Petr   ______________________________________________________________ I can look at compiling with OpenSSL 3.0, I haven't even tried yet. But I would imagineit's all fixable. I don't see anything in the do_sig_verify that requires a non-const key. I would imagineit's just as simple as updating the call sites to match the signatures.I filed bugs:  - https://github.com/tpm2-software/tpm2-pkcs11/issues/686 <https://github.com/tpm2-software/tpm2-pkcs11/issues/686>  - https://github.com/tpm2-software/tpm2-tools/issues/2737 <https://github.com/tpm2-software/tpm2-tools/issues/2737>We'll try to get to these soon, as I would imagine distros are eager to start the process of transitioning over.BillFrom: Jerry Snitselaar <jsnitsel(a)redhat.com&gt; Sent: Monday, May 24, 2021 4:34 PM To: tpm2(a)lists.01.org <tpm2(a)lists.01.org&gt; Subject: [tpm2] tpm2-tools, tpm2-pkcs11, and OpenSSL 3.0  Both tpm2-tools and tpm2-pkcs11 make use of some functions that are being deprecated in openssl 3.0. Are there plans to move away from using those deprecated functions? Currently tpm2-tools will build with -Wno-error=deprecated-declarations, but tpm2-pkcs11 trips over EVP_PKEY_get0_EC_KEY now returning a const EC_KEY *, and ECDSA_do_verify taking a non const parameter. Someone suggested doing something like:        EVP_PKEY_CTX    *pctx = NULL;        if ((pctx = EVP_PKEY_CTX_new(pkey, NULL)) == NULL) {                goto fail;        }        if (EVP_PKEY_verify_init(pctx) != 1 ||            EVP_PKEY_verify(pctx, sigbuf, siglen,            dgstbuf, dgstlen) != 1) {                goto fail;        }  fail:        EVP_PKEY_CTX_free(pctx); but I imagine the ASN.1 framing stuff mentioned in do_sig_verify_ec() would still be an issue, yes? I don't know openssl, so I don't know if you could get away with casting the pointer to EC_KEY *. There is work going on to support openssl 3.0 in RHEL9, so this came up. Regards, Jerry _______________________________________________ tpm2 mailing list -- tpm2(a)lists.01.org To unsubscribe send an email to tpm2-leave(a)lists.01.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ---------- _______________________________________________ tpm2 mailing list -- tpm2(a)lists.01.org To unsubscribe send an email to tpm2-leave(a)lists.01.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s