Hi,
On Tue, Oct 04, 2022 at 02:09:45PM +0100, Richard Purdie wrote:
> On Tue, 2022-10-04 at 15:54 +0300, Mikko Rapeli wrote:
> > On Tue, Oct 04, 2022 at 01:19:41PM +0100, Richard Purdie wrote:
> > > On Tue, 2022-10-04 at 14:38 +0300, Mikko Rapeli wrote:
> > > > On Tue, Oct 04, 2022 at 12:09:18PM +0100, Richard Purdie wrote:
> > > >
> > > > > 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.
> > >
> > > There isn't any feedback there saying dladdr is rejected, just that
> > > they're not sure about the general use case. Getting changes accepted
> > > by upstreams does usually require a bit of work so I'd not quite give
> > > up yet! I can understand it from the maintainers side too, if you're
> > > being asked to accept and maintain something, you do need there to be a
> > > compelling reason for it.
> >
> > openssl has been using these environment variables for decades. I can
> > understand that they hesitate to change any of that. Also because some
> > of the code is obviously trying to avoid any posix dependencies including
> > stat().
> >
> > https://github.com/openssl/openssl/issues/19242
> >
> > "t8m commented 15 days ago
> > I am afraid this is potentially asking for security issues. It would
> > have to be implemented very carefully."
> >
> > "beldmit commented 15 days ago
> > I don't like this approach as a whole. IMHO, we should have some defines
> > to find installation-specific values for a specific installation."
> >
> > "levitte commented 14 days ago
> > It's possible that it would be better if util/wrap.pl became a public
> > tool. Not necessarily exactly as it works now, but something with a
> > similar intent."
> >
> > "levitte commented 14 days ago
> > This isn't just an OpenSSL problem, is it? There are other libraries
> > that are plugable (and essentially, providers are exactly that,
> > plugins), and I imagine that they also have their own custom default
> > location for plugins.
> > Otherwise, the obvious answer would be that you should install things
> > that belong with OpenSSL into its default locations... and that's
> > answered with openssl version -a as said above, or with the openssl info
> > command in later OpenSSL versions."
> >
> > So wrapper it is then.
>
> I was going to write a reply to some of that, I still might, but as I
> was doing it, another idea did just come to mind.
>
> Somewhere I'm guessing openssl has some common init function?
Sadly, there isn't. Not even a common header file. Or at least
I did not find any. The engines, modules, config files and certs
are quite different things compared to the plain shared libraries
which are already found from LD_LIBRARY_PATH.
Cheers,
-Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171393):
https://lists.openembedded.org/g/openembedded-core/message/171393
Mute This Topic: https://lists.openembedded.org/mt/94110827/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
