Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
On Tue, Jul 14, 2020 at 09:08:10PM +0200, shivaramakrishna chakravarthula wrote: > This is exactly similar to what I am looking for. I am using 1.0.2J version > and there are some changes in the next version onwards that causes problems > in SSL connections to older versions when DH key = 256 bytes are used. For > backward compatibility reasons, I need to continue supporting 256 bytes DH > keys for some more time and hence I want to stay on 1.0.2J version for now. > > Anyways, Thanks for sharing the details. Ah, thanks for the details. The change I linked to is not going to be of much use to you, since the build system got completely redone between those versions. I will note that, at least on some systems, you can use sed to change the SONAME of the compiled library before/during the installation process, which may be enough of a workaround for your purposes. -Ben
minimum viable CSR?
Hello, I have domains whose length exceeds the commonName maximum. To create a signing request for such a domain, then, I can’t put the domain in the CSR’s subject. Assuming that I’m interested in just a DV certificate--such that the CSR’s subject DN actually provides no useful information--what would the minimum-viable subject look like from the generation-via-OpenSSL side? Thank you! cheers, -Felipe Gasper
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
This is exactly similar to what I am looking for. I am using 1.0.2J version and there are some changes in the next version onwards that causes problems in SSL connections to older versions when DH key = 256 bytes are used. For backward compatibility reasons, I need to continue supporting 256 bytes DH keys for some more time and hence I want to stay on 1.0.2J version for now. Anyways, Thanks for sharing the details. Thanks, Shiva On Tue, 14 Jul 2020 at 19:03, Benjamin Kaduk wrote: > On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula > wrote: > > Hi, > > > > I have compatibility issues for my application with new versions of > OpenSSL > > and I want to use the older version of OpenSSL with my application. So, I > > want to link my application with an OpenSSL library built with the custom > > name so that it works fine on all systems and I can be assured of using > the > > desired OpenSSL version. I am using RPATH to locate the libraries in > > runtime and I want to make sure my libraries don't conflict with existing > > libraries. > > How old is this "older version"? > > The functionality you want sounds exactly like the "variant SONAMEs > introduced > in commit > https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb > but that's only in 1.1.0g and later. > > -Ben >
openssl-1.1.1-stable-SNAP-20200714 bug Re: openssl-1.1.1-stable-SNAP-20200713 bug
On Mon, Jul 13, 2020 at 08:02:06PM +0300, Nicola Tuveri wrote:
> I independently reached the same failure and I opened a github issue that
> references this report: https://github.com/openssl/openssl/issues/12432
>
> The fix should be coming in the form of
> https://github.com/openssl/openssl/pull/12433
>
> Thanks for reporting this issue!
>
>
> Cheers,
>
> Nicola Tuveri
And this morning we get
Script started on Tue Jul 14 07:05:40 2020
root@doctor:/usr/source/openssl-1.1.1-stable-SNAP-20200714 # make
make depend && make _all
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "en_GB"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
rm -f test/ectest
${LDCMD:-/usr/local/bin/clang10} -pthread -Wa,--noexecstack -Qunused-arguments
-Wall -O3 -L.-o test/ectest test/ectest.o test/libtestutil.a -lcrypto
-pthread
ld: [0;31merror: [0mundefined symbol: EC_GROUP_get_field_type
>>> referenced by ectest.c
>>> test/ectest.o:(custom_generator_test)
ld: [0;31merror: [0mundefined symbol: EC_GROUP_get0_field
>>> referenced by ectest.c
>>> test/ectest.o:(custom_generator_test)
clang: [0;1;31merror: [0mlinker command failed with exit code 1 (use -v to
see invocation)[0m
*** Error code 1
Stop.
make[1]: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200714
*** Error code 1
Stop.
make: stopped in /usr/source/openssl-1.1.1-stable-SNAP-20200714
root@doctor:/usr/source/openssl-1.1.1-stable-SNAP-20200714 # exit
exit
Script done on Tue Jul 14 07:05:54 2020
Error in lines 2126 and 2127 of test/ectest.c
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b
We were not instructed to succumb to the world. -unknown
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote: > Hi, > > I have compatibility issues for my application with new versions of OpenSSL > and I want to use the older version of OpenSSL with my application. So, I > want to link my application with an OpenSSL library built with the custom > name so that it works fine on all systems and I can be assured of using the > desired OpenSSL version. I am using RPATH to locate the libraries in > runtime and I want to make sure my libraries don't conflict with existing > libraries. How old is this "older version"? The functionality you want sounds exactly like the "variant SONAMEs introduced in commit https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb but that's only in 1.1.0g and later. -Ben
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
That was something I have tried initially until I had problems with FIPS mode. I have compiled OpenSSL with FIPS support. But, I see FIPS self-tests failing when I link my application with OpenSSL static libraries. On Tue, 14 Jul 2020 at 17:57, Michael Wojcik wrote: > > From: openssl-users On Behalf Of > shivaramakrishna chakravarthula > > Sent: Tuesday, 14 July, 2020 08:59 > > > I have compatibility issues for my application with new versions of > OpenSSL and > > I want to use the older version of OpenSSL with my application. So, I > want to > > link my application with an OpenSSL library built with the custom name > so that > > it works fine on all systems and I can be assured of using the desired > OpenSSL > > version. > > The right way to fix this, of course, is to fix your application so it > works with a current, supported OpenSSL version. > > Failing that, it would be best to link OpenSSL statically into your > application. Then you don't have to worry about shared object location, and > no one else will be using your outdated OpenSSL. > > -- > Michael Wojcik > >
RE: Compiling OpenSSL shared libraries with custom name on Unix platforms
> From: openssl-users On Behalf Of > shivaramakrishna chakravarthula > Sent: Tuesday, 14 July, 2020 08:59 > I have compatibility issues for my application with new versions of OpenSSL > and > I want to use the older version of OpenSSL with my application. So, I want to > link my application with an OpenSSL library built with the custom name so that > it works fine on all systems and I can be assured of using the desired OpenSSL > version. The right way to fix this, of course, is to fix your application so it works with a current, supported OpenSSL version. Failing that, it would be best to link OpenSSL statically into your application. Then you don't have to worry about shared object location, and no one else will be using your outdated OpenSSL. -- Michael Wojcik
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
Hi, I have compatibility issues for my application with new versions of OpenSSL and I want to use the older version of OpenSSL with my application. So, I want to link my application with an OpenSSL library built with the custom name so that it works fine on all systems and I can be assured of using the desired OpenSSL version. I am using RPATH to locate the libraries in runtime and I want to make sure my libraries don't conflict with existing libraries. Thanks, Shiva On Tue, 14 Jul 2020 at 16:31, Kenneth Goldman wrote: > > From: shivaramakrishna chakravarthula > > > > Is it possible to compile OpenSSL shared libraries with custom > > names on Linux/ Unix platforms to avoid conflicts with installed > > OpenSSL libraries? > > I have tried to modify the SHLIB_EXT in Configure script but it is > > not working. I am sure it is a common problem and someone in this > > group can help. > > If this is just for local testing, I typically build but don't > install. By changing my paths, I can use the local copy. > > If you're sure you have ABI compatibility, could you > manually copy and rename the .so files to /usr/include, > /usr/local/include or equivalent? >
Re: Compiling OpenSSL shared libraries with custom name on Unix platforms
> From: shivaramakrishna chakravarthula > > Is it possible to compile OpenSSL shared libraries with custom > names on Linux/ Unix platforms to avoid conflicts with installed > OpenSSL libraries? > I have tried to modify the SHLIB_EXT in Configure script but it is > not working. I am sure it is a common problem and someone in this > group can help. If this is just for local testing, I typically build but don't install. By changing my paths, I can use the local copy. If you're sure you have ABI compatibility, could you manually copy and rename the .so files to /usr/include, /usr/local/include or equivalent?
Compiling OpenSSL shared libraries with custom name on Unix platforms
Hello, Is it possible to compile OpenSSL shared libraries with custom names on Linux/ Unix platforms to avoid conflicts with installed OpenSSL libraries? I have tried to modify the SHLIB_EXT in Configure script but it is not working. I am sure it is a common problem and someone in this group can help. Thanks in advance. Thanks, Shiva
