On Thu, 2016-02-04 at 03:04 +0000, Rich Salz via RT wrote: > So guys, sorry for dropping the ball. Where are we on this now?
Dropping rt@ since the OPENSSL_NO_STDIO build is actually solved now so RT#3964 looks like it can be closed. I'm choosing to interpret your question in the wider sense of the UEFI build. I have submitted https://github.com/openssl/openssl/pull/631 which matches the EDK2 tree at http://git.infradead.org/users/dwmw2/edk2.git The OpenSSL bits look OK to me; it's mostly just a few fixes for some of the recent cleanups, along with the patch that's been outstanding for a while for RT#3628. I am moderately unhappy with the last commit on the EDK2 side, though. The problem is that the API that the EDK2 CryptoPkg offers to its clients includes a function to get the size of the context. Perhaps we should change that... Qin, is that feasible? In the mean time, I have a horrid "#include <../hmac/hmac_lcl.h>' to make it actually work. Having already done that, I was desensitised enough that elsewhere in the patch I include <../evp/evp_locl.h> just so that we can continue to have an EVP_MD_CTX locally on the stack instead of having to use dynamic allocation for it. Which I concede probably wants cleaning up. But I don't *like* being forced to switch to dynamic allocation. That just introduces failure modes that didn't exist before. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
