From: "Gerd Hoffmann" <kraxel@redhat.com>
To: devel@edk2.groups.io, yi1.li@intel.com
Subject: Re: [edk2-devel] [edk2-staging/OpenSSL11_EOL][PATCH 4/4] Readme: 0322 update
Date: Thu, 23 Mar 2023 09:56:25 +0100 [thread overview]
Message-ID: <miteoxxho3xwnbwutbv32cdqsegzjlh35sk5nn4v5qymb37frr@i2rd5tu2bdfr> (raw)
In-Reply-To: <99a218c205bcc4ddc7ef48ef875dc9361e53926f.1679537389.git.yi1.li@intel.com>
Hi,
> +### 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/8780956da77c949ca42f6c4c3fd6ef7045646ef0
> +(commit: evp: enable legacy pmeth)
> +https://github.com/liyi77/openssl/commit/a2232b35aa308198b61c5734c1bfe1d0263f074b
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.
> +### 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/c3a5b69d8a3465259cfdca8f38b0dc7683b3690e
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/faa5d6781c3af601bcbc11ff199e2955d7ff4306
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.
take care,
Gerd
next prev parent reply other threads:[~2023-03-23 8:56 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 ` Gerd Hoffmann [this message]
2023-03-24 1:46 ` [edk2-devel] " Li, Yi
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=miteoxxho3xwnbwutbv32cdqsegzjlh35sk5nn4v5qymb37frr@i2rd5tu2bdfr \
--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