From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org, docs@lists.yoctoproject.org
Subject: Re: [docs] [PATCH 1/4] openssl-native.bbclass: add bbclass
Date: Tue, 4 Oct 2022 14:38:38 +0300 [thread overview]
Message-ID: <YzwbPsiFw9YDMAWe@nuoska> (raw)
In-Reply-To: <99339c298138b6f300146d81beec455815b11771.camel@linuxfoundation.org>
Hi,
On Tue, Oct 04, 2022 at 12:09:18PM +0100, Richard Purdie wrote:
> Hi Mikko,
>
> Thanks for working on this, particularly with upstream.
>
> On Tue, 2022-10-04 at 13:10 +0300, Mikko Rapeli wrote:
> > Using openssl-native shared libraries correctly is hard. A number
> > of environment variables need to be correctly set or
> > the errors may be really confusing. openssl can be made
> > to detect these paths automatically, but upstream has rejected
> > these ideas. openssl-native provides a wrapper script for 'openssl'
> > binary, but shared library users like python3-cryptgraphy-native
> > need to have the shared libraries working directly. Thus follow
> > example from python3native.bbclass and implement this via
> > openssl-native.bbclass.
> >
> > If full certificate checking is needed, then users
> > also need to DEPEND on ca-certificates-native.
> >
> > See also:
> > https://lists.openembedded.org/g/openembedded-core/topic/93651845#170562
> > https://github.com/openssl/openssl/issues/19242
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > documentation/ref-manual/classes.rst | 11 +++++++++++
> > meta/classes/openssl-native.bbclass | 7 +++++++
> > meta/recipes-connectivity/openssl/openssl_3.0.5.bb | 1 +
> > 3 files changed, 19 insertions(+)
>
> Docs are in a different repo to OE-Core so this patch would need to be
> split.
Ok, will split them.
> I think it is worth referencing this too:
>
> https://github.com/openssl/openssl/pull/19260
Ok, will add.
> I noticed there that the patches have thrown some compiler warnings:
>
> crypto/conf/conf_mod.c:667:20: error: passing 'const char *(int)' to parameter of type 'const void *' converts between void pointer and function pointer [-Werror,-Wpedantic]
> if (dladdr(OpenSSL_version, &info)) {
> crypto/conf/conf_mod.c: In function 'CONF_get1_default_config_file':
> crypto/conf/conf_mod.c:667:20: error: ISO C forbids passing argument 1 of 'dladdr' between function pointer and 'void *' [-Werror=pedantic]
> 667 | if (dladdr(OpenSSL_version, &info)) {
> | ^~~~~~~~~~~~~~~
> In file included from /usr/aarch64-linux-gnu/include/link.h:25,
> from crypto/conf/conf_mod.c:34:
> /usr/aarch64-linux-gnu/include/dlfcn.h:98:32: note: expected 'const void *' but argument is of type 'const char * (*)(int)'
> 98 | extern int dladdr (const void *__address, Dl_info *__info)
>
>
> It may be worth fixing those just in case they consider the patch.
Yes, but the general design of using dladdr(OpenSSL_version,...) did not
get any positive comments in the bug report so I think this is wasted
effort.
> I'm wondering whether we should just carry those patches? They don't
> look so invasive and it would save complicating things elsewhere in our
> codebase...
I don't think so. For every variable the patch is annoyingly different
and there are merge/rebase conflicts with newer upstream releases
already.
I think pyton3native.bbclass sets the example. Variables need to be set
for openssl to work correctly after relocation to paths not known at
compile time. Same applies to any code which needs to dlopen() something
or which has custom locations for modules, data or configuration files.
Cheers,
-Mikko
next prev parent reply other threads:[~2022-10-04 11:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 10:10 [PATCH 1/4] openssl-native.bbclass: add bbclass Mikko Rapeli
2022-10-04 11:09 ` [docs] " Richard Purdie
2022-10-04 11:38 ` Mikko Rapeli [this message]
2022-10-04 12:19 ` Richard Purdie
2022-10-04 12:54 ` Mikko Rapeli
2022-10-04 13:09 ` Richard Purdie
2022-10-04 13:32 ` Mikko Rapeli
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-all 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=YzwbPsiFw9YDMAWe@nuoska \
--to=mikko.rapeli@linaro.org \
--cc=docs@lists.yoctoproject.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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