From: "Li, Yi" <yi1.li@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [edk2-staging/OpenSSL11_EOL][PATCH 4/4] Readme: 0322 update
Date: Fri, 24 Mar 2023 01:46:44 +0000 [thread overview]
Message-ID: <SJ1PR11MB62271DA1C0AB88533470F8C2C5849@SJ1PR11MB6227.namprd11.prod.outlook.com> (raw)
In-Reply-To: <miteoxxho3xwnbwutbv32cdqsegzjlh35sk5nn4v5qymb37frr@i2rd5tu2bdfr>
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/8780956da77c949ca42f6c4c3fd6
>> +ef7045646ef0
>> +(commit: evp: enable legacy pmeth)
>> +https://github.com/liyi77/openssl/commit/a2232b35aa308198b61c5734c1bf
>> +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
next prev parent reply other threads:[~2023-03-24 1:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 2:44 [edk2-staging/OpenSSL11_EOL][PATCH 0/4] Openssl 3.0 POC update Mar 22 Li, Yi
2023-03-23 2:44 ` [edk2-staging/OpenSSL11_EOL][PATCH 1/4] bugfix: use null md5 onlyif no-md5 defined Li, Yi
2023-03-23 2:44 ` [edk2-staging/OpenSSL11_EOL][PATCH 2/4] CryptoPkg: remove unnecessary sig, ec and rsa prov Li, Yi
2023-03-23 2:44 ` [edk2-staging/OpenSSL11_EOL][PATCH 3/4] CryptoPkg: update openssl submodule Li, Yi
2023-03-23 2:44 ` [edk2-staging/OpenSSL11_EOL][PATCH 4/4] Readme: 0322 update Li, Yi
2023-03-23 8:56 ` [edk2-devel] " Gerd Hoffmann
2023-03-24 1:46 ` Li, Yi [this message]
2023-03-24 6:11 ` Yao, Jiewen
2023-03-24 7:50 ` Li, Yi
2023-03-24 7:54 ` Yao, Jiewen
2023-03-23 16:00 ` [edk2-devel] [edk2-staging/OpenSSL11_EOL][PATCH 0/4] Openssl 3.0 POC update Mar 22 Michael D Kinney
2023-03-24 17:07 ` Yao, Jiewen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ1PR11MB62271DA1C0AB88533470F8C2C5849@SJ1PR11MB6227.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox