Re: [edk2-devel] [edk2-staging/OpenSSL11_EOL][PATCH 4/4] Readme: 0322 update

["Yao, Jiewen" <jiewen.yao@intel.com>]

We have 2 level APIs.

1) EDKII other code -> CryptoPkg.
2) CryptoPkg -> Openssl.

Current strategy of openssl 3.0 update is to keep both 1) and 2). That is minimal impact.

Do you think if we can keep 1) and only update 2) to use new API in openssl 3.0?



> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Li, Yi
> Sent: Friday, March 24, 2023 9:47 AM
> To: Gerd Hoffmann <kraxel@redhat.com>; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-staging/OpenSSL11_EOL][PATCH 4/4]
> Readme: 0322 update
> 
> Hi Gerd,
> 
> Thanks for review,
> 
> >> +### Level 2: A bit like workaround, with possibility of upstream to
> >> +openssl 1. Enable the legacy path for X509 pubkey decode and pmeth
> >> +initialization, The purpose is to avoid the use of EN/DECODE and
> Signature provider, will reduce size about 90KB.
> >> +(commit: x509: enable legacy path in pub decode)
> >>
> +https://github.com/liyi77/openssl/commit/8780956da77c949ca42f6c4c3fd
> 6
> >> +ef7045646ef0
> >> +(commit: evp: enable legacy pmeth)
> >>
> +https://github.com/liyi77/openssl/commit/a2232b35aa308198b61c5734c1
> bf
> >> +e1d0263f074b
> 
> >I suspect that is not going to work well long-term, probably openssl will
> remove the code paths they consider being "legacy" at some point in the
> future.  Probably not 3.0.x but maybe in 3.1 branch.
> 
> Yes, I think in long-term the better way is to remove all legacy code paths,
> this will also help reduce the size.
> The problem is that a large number of legacy APIs are currently used in the
> EDK2 code.
> In the future, it may be a big update to throw all the legacy code.
> 
> >> +### Level 3: Totally workaround and hard to upstream to openssl, may
> >> +need scripts to apply them inside EDK2 1. Provider cut.
> >> +(commit: CryptoPkg: add own openssl provider)
> >> +https://github.com/liyi77/edk2-
> staging/commit/c3a5b69d8a3465259cfdca8
> >> +f38b0dc7683b3690e
> 
> >Allow people implement their own providers looks like an openssl feature to
> me.  So I don't think this will be a big problem to maintain, I expect they try
> to keep the interfaces stable to not break apps doing so.
> 
> >The only little detail we do differently here is to remove the default
> providers so LTO can actually remove the unused code.
> 
> >> +(commit: x509: remove print function 7KB)
> >>
> +https://github.com/liyi77/openssl/commit/faa5d6781c3af601bcbc11ff199e
> >> +2955d7ff4306
> 
> >Did you double-check this doesn't break something?
> 
> >It did for me, due to some code in openssl depending on a working
> bio_sprintf() implementation.
> 
> I don't do any more test than unit test.
> I am sick of this part, but I currently have no other way to reduce the size. I
> would like to drop those changes first if i find another way.
> 
> Regards,
> Yi
> 
> 
> 
> 
>