Not to hijack this thread, I was already working on an [RFC: EDK2 Crypto Architecture Reorganization](https://github.com/tianocore/edk2-crypto/discussions/2) for the future of [edk2-crypto](https://github.com/tianocore/edk2-crypto). In light of this TPM work, I've been thinking about how to support features that need direct crypto access while still enabling faster, more reliable OpensslPkg updates.
The core idea is that code within the EDK2 repository must use BaseCryptLib.h as the established contract, which maintains backward compatibility and enforces proper abstraction. However features like this that need direct crypto access can link directly to crypto providers. However these features manage their own submodule updates / crypto independently. I would prefer to keep this out of edk2 if we can. Is there opposition to adding this to Edk2-Platforms as Michael suggested in the original thread? Or maybe we could have another location for features that will take ownership of their own crypto and could update crypto when they're ready? Feel free to provide suggestions to the discussion thread. I'm happy to make discuss changes that align with our ecosystem needs. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121723): https://edk2.groups.io/g/devel/message/121723 Mute This Topic: https://groups.io/mt/116737708/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
