liblegacy.a does not work unless compiled with -static

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

liblegacy.a does not work unless compiled with -static

Guido Vranken
When I configure using "./config enable-legacy" it creates providers/liblegacy.a, then in the program I link with it, OSSL_PROVIDER_load fails (returns NULL).

When I configure using "./config enable-legacy -static" it works as expected.

However, building with -static fails on OSS-Fuzz when building with sanitizers, and I need the .a file instead of the .so file for fuzzing.

So, is it possible to configure using "./config enable-legacy" and have a working liblegacy.a? Is this a bug?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Matt Caswell-2
liblegacy.a is an internal artifact! You're not supposed to link your
applications against it!

You are supposed to link against libcrypto normally. If legacy.so isn't
in the default install location then make sure the OPENSSL_MODULES
environment variable is pointing at its directory.

Matt


On 01/05/2020 17:14, Guido Vranken wrote:

> When I configure using "./config enable-legacy" it creates
> providers/liblegacy.a, then in the program I link with it,
> OSSL_PROVIDER_load fails (returns NULL).
>
> When I configure using "./config enable-legacy -static" it works as
> expected.
>
> However, building with -static fails on OSS-Fuzz when building with
> sanitizers, and I need the .a file instead of the .so file for fuzzing.
>
> So, is it possible to configure using "./config enable-legacy" and have
> a working liblegacy.a? Is this a bug?
>
> Thanks
Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Guido Vranken
OK I see, thanks.

On Fri, May 1, 2020 at 6:27 PM Matt Caswell <[hidden email]> wrote:
liblegacy.a is an internal artifact! You're not supposed to link your
applications against it!

You are supposed to link against libcrypto normally. If legacy.so isn't
in the default install location then make sure the OPENSSL_MODULES
environment variable is pointing at its directory.

Matt


On 01/05/2020 17:14, Guido Vranken wrote:
> When I configure using "./config enable-legacy" it creates
> providers/liblegacy.a, then in the program I link with it,
> OSSL_PROVIDER_load fails (returns NULL).
>
> When I configure using "./config enable-legacy -static" it works as
> expected.
>
> However, building with -static fails on OSS-Fuzz when building with
> sanitizers, and I need the .a file instead of the .so file for fuzzing.
>
> So, is it possible to configure using "./config enable-legacy" and have
> a working liblegacy.a? Is this a bug?
>
> Thanks
Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

OpenSSL - User mailing list
In reply to this post by Matt Caswell-2
Hm, so DSO support is a requirement for legacy crypto now?  That probably needs to be made explicit, and see if the project gets pushback.


Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Sam Roberts
On Fri, May 1, 2020 at 10:22 AM Salz, Rich via openssl-users
<[hidden email]> wrote:
> Hm, so DSO support is a requirement for legacy crypto now?  That probably needs to be made explicit, and see if the project gets pushback.

It would mean legacy alg support would not exist for Node.js binary
distributions, but I'm still figuring out how many legacy algs we
support.

How hard we'd push back on that would depend on how hard our users
push back... but we won't know that until ossl3 makes it into a new
major of node, probably spring 2021, when it might be too late to
change anything.
Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Richard Levitte - VMS Whacker-2
In reply to this post by OpenSSL - User mailing list
On Fri, 01 May 2020 19:22:13 +0200,
Salz, Rich via openssl-users wrote:
>
> Hm, so DSO support is a requirement for legacy crypto now?  That
> probably needs to be made explicit, and see if the project gets
> pushback.

No.  When DSO support is turned off, the legacy provider code becomes
part of libcrypto, in an inaccessible state (in other words, you still
have to "load" it).

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Dr Paul Dale
I’ve been wondering if an option to build the legacy provider into libcrypto (like the null and default providers) is worthwhile.

Given this conservation, it seems it might be.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




On 2 May 2020, at 5:30 pm, Richard Levitte <[hidden email]> wrote:

On Fri, 01 May 2020 19:22:13 +0200,
Salz, Rich via openssl-users wrote:

Hm, so DSO support is a requirement for legacy crypto now?  That
probably needs to be made explicit, and see if the project gets
pushback.

No.  When DSO support is turned off, the legacy provider code becomes
part of libcrypto, in an inaccessible state (in other words, you still
have to "load" it).

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Sam Roberts
In reply to this post by Richard Levitte - VMS Whacker-2
On Sat, May 2, 2020 at 12:31 AM Richard Levitte <[hidden email]> wrote:
> No.  When DSO support is turned off, the legacy provider code becomes
> part of libcrypto, in an inaccessible state (in other words, you still
> have to "load" it).

Using OSSL_PROVIDER_load(NULL, "legacy")?

My first try after a static only build (and delete of all .so files)
got an error from that, but if its the correct way, I'll investigate
more.

Sam
Reply | Threaded
Open this post in threaded view
|

Re: liblegacy.a does not work unless compiled with -static

Matt Caswell-2


On 02/05/2020 16:39, Sam Roberts wrote:

> On Sat, May 2, 2020 at 12:31 AM Richard Levitte <[hidden email]> wrote:
>> No.  When DSO support is turned off, the legacy provider code becomes
>> part of libcrypto, in an inaccessible state (in other words, you still
>> have to "load" it).
>
> Using OSSL_PROVIDER_load(NULL, "legacy")?
>
> My first try after a static only build (and delete of all .so files)
> got an error from that, but if its the correct way, I'll investigate
> more.


Yes, that is the correct method.

Matt