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: OpenSSL version 3.0.0-alpha1 published
On Thu, Apr 30, 2020 at 9:27 PM Richard Levitte wrote: > Yes, running from the DESTDIR "installation" gets you into trouble. > DESTDIR is intended to be a staging directory, i.e. a place to put Fair enough, I don't have to use DESTDIR, I configure with openssldir and prefix set to a sandbox now. We statically link openssl to get a self-contained binary. I'm not sure if --no-shared was sufficient to "build in" the legacy algs. Provider load failed, reasonably expectedly, but whether our test suite is failing because of missing legacy won't be clear to me until more of the superficial failures are fixed. Is there a reason two terms, "modules" and "providers", are both used? Are there modules that are NOT providers? It is confusing to use different names to describe the same thing, so if modules are providers, perhaps one name could be used consistently.
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
Re: OpenSSL version 3.0.0-alpha1 published
Reminder that in git master and 3.0.0, CAST5 gives the wrong output: https://github.com/openssl/openssl/issues/11459 (this proof of concept was made before you moved CAST5 to liblegacy, so just put OSSL_PROVIDER_load(nullptr, "legacy"); in there to make it work) On Thu, Apr 23, 2020 at 4:30 PM OpenSSL wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > >OpenSSL version 3.0 alpha 1 released > > >OpenSSL - The Open Source toolkit for SSL/TLS >https://www.openssl.org/ > >OpenSSL 3.0 is currently in alpha. > >OpenSSL 3.0 alpha 1 has now been made available. > >Note: This OpenSSL pre-release has been provided for testing ONLY. >It should NOT be used for security critical purposes. > >Specific notes on upgrading to OpenSSL 3.0 from previous versions, as > well >as known issues are available on the OpenSSL Wiki, here: > > https://wiki.openssl.org/index.php/OpenSSL_3.0 > >The alpha release is available for download via HTTPS and FTP from the >following master locations (you can find the various FTP mirrors under >https://www.openssl.org/source/mirror.html): > > * https://www.openssl.org/source/ > * ftp://ftp.openssl.org/source/ > >The distribution file name is: > > o openssl-3.0.0-alpha1.tar.gz > Size: 9530120 > SHA1 checksum: 4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06 > SHA256 checksum: > 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57 > >The checksums were calculated using the following commands: > > openssl sha1 openssl-3.0.0-alpha1.tar.gz > openssl sha256 openssl-3.0.0-alpha1.tar.gz > >Please download and check this $LABEL release as soon as possible. >To report a bug, open an issue on GitHub: > > https://github.com/openssl/openssl/issues > >Please check the release notes and mailing lists to avoid duplicate >reports of known issues. (Of course, the source is also available >on GitHub.) > >Yours, > >The OpenSSL Project Team. > > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g > RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk > I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E > cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8 > hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll > Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F > hIr11rxXNxtBRKUSlOUyJATZn0sV6g== > =uRpM > -END PGP SIGNATURE- >
liblegacy.a does not work unless compiled with -static
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: FFT algorithm for BIGNUM multiplication
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Dan Fulger > Sent: Friday, May 01, 2020 08:03 > > off topic: > > "till" is correct and older than "until". > > https://www.merriam-webster.com/dictionary/till > https://en.wiktionary.org/wiki/till > line 786915 in file http://www.gutenberg.org/cache/epub/673/pg673.txt > > and all four paper dictionaries I have in my home (two of them do not even > mention "til"). Argh. Now that you mention it, I remember reading this some years ago. I should have checked before posting that. (You'd think after decades of mailing lists and Usenet and whatnot I'd have acquired that habit...) I stand corrected. Thanks.
RE: FFT algorithm for BIGNUM multiplication
off topic: "till" is correct and older than "until". https://www.merriam-webster.com/dictionary/till https://en.wiktionary.org/wiki/till line 786915 in file http://www.gutenberg.org/cache/epub/673/pg673.txt and all four paper dictionaries I have in my home (two of them do not even mention "til").
Re: OpenSSL version 3.0.0-alpha1 published
On Fri, May 1, 2020 at 6:36 AM Richard Levitte wrote: > > On Sun, 26 Apr 2020 11:35:14 +0200, > Yann Ylavic wrote: > > > > On Sun, Apr 26, 2020 at 12:15 AM Kurt Roeckx wrote: > > > > > > On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote: > > > > > > > > - DH_bits(dh) (used for logging only in httpd) > > > > Replaced by BN_num_bits(DH_get0_p(dh)). > > > > Not sure this one should be deprecated, it seems to be used in several > > > > places in openssl codebase still, no replacement? > > > > > > I think the replacement is using the EVP_PKEY API and then use > > > EVP_PKEY_bits() > > > > Sure, but if all you have is a DH object (say obtained by > > DH_get_2048_256() or PEM_read_bio_DHparams()), the EVP_PKEY API does > > not help. > > It seems a bit odd to me that DH_bits() or DH_security_bits() are > > deprecated, but not DH_get0_*() or DH_get_length() for instance. > > The DH_get0_* functions are useful in contructing other low-level DH > objects using the same numbers as the one you currently have. I don't > quite see that DH_bits() would be useful in that manner. > > Along that line of thinking, I agree that it's odd that > DH_get_length() wasn't deprecated. I can't remember if it was > discussed in particular... it might simply be an omission. > > All that being said, DH_bits() was undeprecated yesterday. See > https://github.com/openssl/openssl/pull/11669 Thanks for that. Regards, Yann.
Re: OpenSSL version 3.0.0-alpha1 build failed
On 30/04/2020 22:44, Matt Caswell wrote: > This appears to be a bug in perl. You have a very old version of perl > (the oldest we support is 5.10.0). It's probably worth trying to upgrade it. I've seen a very similar (but not quite the same) crash in an older version of perl on a different platform. Please see the workaround procedure I've documented here: https://github.com/openssl/openssl/issues/11694 Please could you try this out and let me know if it works? Thanks Matt > > Matt > > > On 30/04/2020 22:12, Ken Goldman wrote: >> My build failed with the below. >> >> x86_64 Linux kernel 2.6.32 >> RHEL 6.7 >> Perl 5.10.1 >> >> Everything through 1.1.1e was successful. >> >> ~~ >> >> >> ./config >> Operating system: x86_64-whatever-linux2 >> Configuring OpenSSL version 3.0.0-alpha1 for target linux-x86_64 >> Using os-specific seed configuration >> *** glibc detected *** /usr/bin/perl: double free or corruption (out): >> 0x02a401e0 *** >> === Backtrace: = >> /lib64/libc.so.6[0x3c2fa75dee] >> /lib64/libc.so.6[0x3c2fa78c80] >> /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x6a5)[0x3c35ab93c5] >> /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] >> /usr/lib64/perl5/CORE/libperl.so(Perl_av_undef+0x58)[0x3c35aa4018] >> /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x598)[0x3c35ab92b8] >> /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] >> /usr/lib64/perl5/CORE/libperl.so(Perl_sv_clear+0x47c)[0x3c35ab919c] >> /usr/lib64/perl5/CORE/libperl.so(Perl_sv_free2+0x52)[0x3c35ab95d2] >> /usr/lib64/perl5/CORE/libperl.so(Perl_hv_free_ent+0x42)[0x3c35a9e8c2] >> /usr/lib64/perl5/CORE/libperl.so[0x3c35a9fde1] >> /usr/lib64/perl5/CORE/libperl.so(Perl_hv_clear+0xfa)[0x3c35a9ffea] >> /usr/lib64/perl5/CORE/libperl.so(Perl_leave_scope+0xea8)[0x3c35ad6258] >> /usr/lib64/perl5/CORE/libperl.so(Perl_pp_unstack+0x59)[0x3c35aa8419] >> /usr/lib64/perl5/CORE/libperl.so(Perl_runops_standard+0x16)[0x3c35aa4b06] >> /usr/lib64/perl5/CORE/libperl.so(perl_run+0x338)[0x3c35a4d0d8] >> /usr/bin/perl(main+0x154)[0x400e74] >> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3c2fa1ed1d] >> [snipped] >>
