Re: liblegacy.a does not work unless compiled with -static
On 02/05/2020 16:39, Sam Roberts wrote: > On Sat, May 2, 2020 at 12:31 AM Richard Levitte 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
Re: liblegacy.a does not work unless compiled with -static
On Sat, May 2, 2020 at 12:31 AM Richard Levitte 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
Re: liblegacy.a does not work unless compiled with -static
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 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 levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/
Re: liblegacy.a does not work unless compiled with -static
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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: liblegacy.a does not work unless compiled with -static
On Fri, May 1, 2020 at 10:22 AM 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. 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.
Re: liblegacy.a does not work unless compiled with -static
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.
Re: liblegacy.a does not work unless compiled with -static
OK I see, thanks. On Fri, May 1, 2020 at 6:27 PM Matt Caswell 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 >
Re: liblegacy.a does not work unless compiled with -static
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
