AW: Performance Issue With OpenSSL 1.1.1c
> I think I have tracked down the change in 1.1.1c that is causing this. > It is the addition of the DEVRANDOM_WAIT functionality for linux in > e_os.h and crypto/rand/rand_unix.c. lighttpd (libcrypto) is waiting in > a select() call on /dev/random. After this eventually wakes up, it then > reads from /dev/urandom. OpenSSL 1.1.1b did not do this, but instead > just read from /dev/urandom. Is there more information about this > change (i.e., a rationale)? I did not see anything in the CHANGES file > about it. The original discussions for this change can be found on GitHub: - issue #8215, fixed by pull request #8251 - issue #8416, fixed by pull request #8428 (see links below). And you are right, the change should have been mentioned in the CHANGES file. Apologies for that. HTH, Matthias https://github.com/openssl/openssl/issues/8215 https://github.com/openssl/openssl/pull/8251 https://github.com/openssl/openssl/issues/8416 https://github.com/openssl/openssl/pull/8428
Re: Performance Issue With OpenSSL 1.1.1c
jayf0s...@roadrunner.com said: > I think I have tracked down the change in 1.1.1c that is causing this. It > is the addition of the DEVRANDOM_WAIT functionality for linux in e_os.h and > crypto/rand/rand_unix.c. lighttpd (libcrypto) is waiting in a select() call > on /dev/random. ... I have seen similar delays that don't involve OpenSSL. [ 10.585102] [drm] Initialized qxl 0.1.0 20120117 for :00:02.0 on minor 0 [ 10.605881] EDAC sbridge: Seeking for: PCI ID 8086:3ca0 [ 10.605887] EDAC sbridge: Ver: 1.1.2 [ 540.286117] random: crng init done [ 540.287631] random: 7 urandom warning(s) missed due to ratelimiting May 18 20:59:00 ntp1 kernel: [drm] Initialized qxl 0.1.0 20120117 for :00:02.0 on minor 0 May 18 21:09:55 ntp1 kernel: random: crng init done -- These are my opinions. I hate spam.
Re: Performance Issue With OpenSSL 1.1.1c
I also noticed that with 1.1.1b, the CFLAGS automatically included '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the CFLAGS. was this dropped? I added '-Wall -O3' to the CFLAGS, but this did not seem to have any affect on the performance issue (unrelated?). This is for a 32-bit ARM build. Jay Well, for what it is worth, on ye old Solaris 10 sparc world things were horrific before and horrific after an upgrade. No optimization at all. Slightly better but still horrific : beta # uname -a SunOS beta 5.10 Generic_150400-65 sun4u sparc SUNW,SPARC-Enterprise beta # beta # psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) beta # * * * before * * * beta # /usr/local/bin/openssl speed rsa Doing 512 bits private rsa's for 10s: 12665 512 bits private RSA's in 9.99s Doing 512 bits public rsa's for 10s: 239095 512 bits public RSA's in 10.00s Doing 1024 bits private rsa's for 10s: 2453 1024 bits private RSA's in 9.99s Doing 1024 bits public rsa's for 10s: 95296 1024 bits public RSA's in 10.00s Doing 2048 bits private rsa's for 10s: 400 2048 bits private RSA's in 10.01s Doing 2048 bits public rsa's for 10s: 29899 2048 bits public RSA's in 10.00s Doing 3072 bits private rsa's for 10s: 164 3072 bits private RSA's in 10.04s Doing 3072 bits public rsa's for 10s: 14204 3072 bits public RSA's in 10.00s Doing 4096 bits private rsa's for 10s: 78 4096 bits private RSA's in 10.00s Doing 4096 bits public rsa's for 10s: 8257 4096 bits public RSA's in 10.00s Doing 7680 bits private rsa's for 10s: 16 7680 bits private RSA's in 10.56s Doing 7680 bits public rsa's for 10s: 2439 7680 bits public RSA's in 10.00s Doing 15360 bits private rsa's for 10s: 3 15360 bits private RSA's in 13.18s Doing 15360 bits public rsa's for 10s: 622 15360 bits public RSA's in 10.00s OpenSSL 1.1.1b 26 Feb 2019 built on: Tue Mar 26 06:51:39 2019 UTC options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/developerstudio12.6/bin/cc -KPIC -m64 -Xa -g -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -xdebugformat=dwarf -xstrconst -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO signverifysign/s verify/s rsa 512 bits 0.000789s 0.42s 1267.8 23909.5 rsa 1024 bits 0.004073s 0.000105s245.5 9529.6 rsa 2048 bits 0.025025s 0.000334s 40.0 2989.9 rsa 3072 bits 0.061220s 0.000704s 16.3 1420.4 rsa 4096 bits 0.128205s 0.001211s 7.8825.7 rsa 7680 bits 0.66s 0.004100s 1.5243.9 rsa 15360 bits 4.39s 0.016077s 0.2 62.2 beta # * * * after * * * beta # /usr/local/bin/openssl version OpenSSL 1.1.1c 28 May 2019 beta # /usr/local/bin/openssl speed rsa Doing 512 bits private rsa's for 10s: 13654 512 bits private RSA's in 9.99s Doing 512 bits public rsa's for 10s: 238275 512 bits public RSA's in 10.00s Doing 1024 bits private rsa's for 10s: 2665 1024 bits private RSA's in 10.00s Doing 1024 bits public rsa's for 10s: 95371 1024 bits public RSA's in 9.99s Doing 2048 bits private rsa's for 10s: 431 2048 bits private RSA's in 9.99s Doing 2048 bits public rsa's for 10s: 29914 2048 bits public RSA's in 10.00s Doing 3072 bits private rsa's for 10s: 164 3072 bits private RSA's in 10.04s Doing 3072 bits public rsa's for 10s: 14256 3072 bits public RSA's in 9.99s Doing 4096 bits private rsa's for 10s: 80 4096 bits private RSA's in 10.06s Doing 4096 bits public rsa's for 10s: 8278 4096 bits public RSA's in 10.00s Doing 7680 bits private rsa's for 10s: 16 7680 bits private RSA's in 10.34s Doing 7680 bits public rsa's for 10s: 2437 7680 bits public RSA's in 9.99s Doing 15360 bits private rsa's for 10s: 3 15360 bits private RSA's in 13.17s Doing 15360 bits public rsa's for 10s: 621 15360 bits public RSA's in 10.01s OpenSSL 1.1.1c 28 May 2019 built on: Tue May 28 19:37:03 2019 UTC options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/developerstudio12.6/bin/cc -KPIC -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -xstrconst -Xa -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrco
Re: Performance Issue With OpenSSL 1.1.1c
Jay Foster wrote in <84571f12-68b3-f7ee-7896-c891a2e25...@roadrunner.com>:
|On 5/28/2019 10:39 AM, Jay Foster wrote:
|> I built OpenSSL 1.1.1c from the recent release, but have noticed what
|> seems like a significant performance drop compared with 1.1.1b. I
|> notice this when starting lighttpd. With 1.1.1b, lighttpd starts in a
|> few seconds, but with 1.1.1c, it takes several minutes.
|>
|> I also noticed that with 1.1.1b, the CFLAGS automatically included
|> '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the
|> CFLAGS. was this dropped? I added '-Wall -O3' to the CFLAGS, but
|> this did not seem to have any affect on the performance issue
|> (unrelated?).
|>
|> This is for a 32-bit ARM build.
|>
|> Jay
|>
|I think I have tracked down the change in 1.1.1c that is causing this.
|It is the addition of the DEVRANDOM_WAIT functionality for linux in
|e_os.h and crypto/rand/rand_unix.c. lighttpd (libcrypto) is waiting in
|a select() call on /dev/random. After this eventually wakes up, it then
|reads from /dev/urandom. OpenSSL 1.1.1b did not do this, but instead
|just read from /dev/urandom. Is there more information about this
|change (i.e., a rationale)? I did not see anything in the CHANGES file
|about it.
I do not know why lighttpd ends up on /dev/random for you, but in
my opinion the Linux random stuff is both sophisticated and sucks.
The latter because (it seems that many) people end up using
haveged or similar to pimp up their entropy artificially, whereas
on the other side the initial OS seeding is no longer truly
supported. Writing some seed to /dev/urandom does not bring any
entropy to the "real" pool.
This drove me insane on my elder boxes, and on my VM server (which
suddenly required minutes for booting, but mind you that was
actually really OpenSSH hanging on, just the boot messages made me
think something else) i even had to log in twice to end a hang of
half on hour -- by doing one (maybe two) keypress(es)!
Whereas that box does reasonable work by generating I/O and thus
I/O based entropy, once it is up. But the pool cannot be feeded
until we get there. I installed haveged, but this is ridiculous!
Therefore i have written a small program entropy-saver.c which
saves and restores entropy to the real pool, which is still
possible (though the interface is deprecated).
This works just fantastic, and even on my brand new laptop it is
of value. And Linux does not take the proposed bits for granted
but about halfs that. Feel free to use it. Do not use it in
conjunction with haveged or something, or take care for the order.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
/*@ Save and load Linux (2.6.0+) entropy.
*@ Different to "cat XY > /dev/urandom" this increments "entropy_avail".
*@ NOTE: this will not work correctly if used in conjunction with haveged
*@ or a similar entropy managing daemon; *unless* it is ensured it loads
*@ entropy before, and saves entropy after the daemon lifetime!
*@ Synopsis: entropy-saver save [file]
*@ Synopsis: entropy-saver load [file]
*@ "file" defaults to a_RAND_FILE_STORE.
*
* 2019 Steffen (Daode) Nurpmeso .
* Public Domain
*/
/* Random device*/
#define a_RAND_DEV "/dev/random"
/* Maximum number of bytes we handle (must be LT INT_MAX/8!) */
#define a_RAND_NO_BYTES 512
/* When saving, the minimum number of entropy_avail we keep in the pool.
* _This_ is checked after we have read once (512 we test initially).
* We will refuse to save a dump which offers less than 128 bits. */
#define a_RAND_ENTROPY_COUNT_MIN 1024
/* Default storage */
#define a_RAND_FILE_STORE "/var/lib/misc/random.dat"
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if KERNEL_VERSION(2,6,0) >= LINUX_VERSION_CODE
# error Linux kernel version and IOCTL usage incompatible.
#endif
static char const a_rand_file_store[] = a_RAND_FILE_STORE;
int
main(int argc, char **argv){
enum {a_LOAD, a_SAVE};
struct{
struct rand_pool_info rpi;
char buf[a_RAND_NO_BYTES];
} x;
char *rpibuf; /* To make C++ happy: rpi.buf is char[0] */
ssize_t len;
char const *store;
int rv, accu, randfd, storfd, iocarg;
/* Command line handling */
if(argc < 2 || argc > 3)
goto jeuse;
if(!strcmp(argv[1], "load"))
accu = a_LOAD;
else if(!strcmp(argv[1], "save"))
accu = a_SAVE;
else{
jeuse:
fprintf(stderr,
"Synopsis: entropy-saver save [storage-file]\n"
"Synopsis: entropy-saver load [storage-file]\n"
"\n"
"storage-file defaults to " a_RAND_FILE_STORE "\n"
"Exit: sysexits.h: EX_USAGE, EX_NOPERM, EX_IOERR, EX_TEMPFAIL\n");
rv = EX_USAGE;
goto j_leave;
}
openlog("entropy-saver",
#ifdef LOG_PERROR
RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Tuesday, May 28, 2019 14:21 > > > On May 28, 2019, at 11:35 AM, Michael Wojcik > wrote: > > > > Don't tell us about the ldd output. Show us. ldd output is short enough to > include in an email message. > > More useful than "ldd" output, is output from "readelf -d", > showing the NEEDED libraries, any RPATH, ... Well, yes, for this specific case (i.e. when looking at a dynamic-loading issue for a platform that uses ELF binaries and has the readelf utility). But I was making a more generic point: don't just tell us how you interpreted the result of an investigation when you can reasonably show us the actual evidence as well. This of course is part of the eternal and widespread problem of not knowing how to ask a good question. I'm trying to offer some general advice in that area (without being quite as verbose as ESR's "How To Ask Questions The Smart Way"). -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: Performance Issue With OpenSSL 1.1.1c
On 5/28/2019 10:39 AM, Jay Foster wrote: I built OpenSSL 1.1.1c from the recent release, but have noticed what seems like a significant performance drop compared with 1.1.1b. I notice this when starting lighttpd. With 1.1.1b, lighttpd starts in a few seconds, but with 1.1.1c, it takes several minutes. I also noticed that with 1.1.1b, the CFLAGS automatically included '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the CFLAGS. was this dropped? I added '-Wall -O3' to the CFLAGS, but this did not seem to have any affect on the performance issue (unrelated?). This is for a 32-bit ARM build. Jay I think I have tracked down the change in 1.1.1c that is causing this. It is the addition of the DEVRANDOM_WAIT functionality for linux in e_os.h and crypto/rand/rand_unix.c. lighttpd (libcrypto) is waiting in a select() call on /dev/random. After this eventually wakes up, it then reads from /dev/urandom. OpenSSL 1.1.1b did not do this, but instead just read from /dev/urandom. Is there more information about this change (i.e., a rationale)? I did not see anything in the CHANGES file about it. Jay
Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
In general, this occurs because you have some other libraries (from your system) that link against libcrypto.so.1.0.0. In theory, it should all just work, but in practice I've often found my application did not work as expected. Specifically, I'd get a TLS end point that did not speak ECDSA (1.0 does not, 1.1 does). You have make a pass through the shared objects that your application references (ldd output), and then using ldd, you can discover which ones want libcrypto.so.1.0.0, and then you either have to upgrade those libraries, or you may have to compile them from source. The last time I did this, I found it was libpqclient5 (a postgresql client library), and that I was able to upgrade it to libpqclient10 rather than resort to source code. Minimal distributions like containerized alpinelinux also help to minimize your dependancies. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature
Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
> On May 28, 2019, at 11:35 AM, Michael Wojcik > wrote: > > Don't tell us about the ldd output. Show us. ldd output is short enough to > include in an email message. More useful than "ldd" output, is output from "readelf -d", showing the NEEDED libraries, any RPATH, ... -- Viktor.
Re: Slightly funny tar ball for openssl 1.1.1c ?
Dennis Clarke wrote in :
|
|>> beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf -
|>> tar: pax_global_header: typeflag 'g' not recognized, converting to
|>> regular file
|>> beta $
|>>
|>> Must be a gnu tar thing?
|>
|> Hi Dennis,
|>
|> it's not a bug, it's a feature. ;-)
|>
|> No seriously: it's the `git archive` command which is used to export \
|> the tree
|> into a tarfile. It adds an extended header containing the commit \
|> hash of the
|> commit which was exported. Older tar programs don't know how to deal
|> with that header and are a bit confused about it.
|
|Yep. Old POSIX tar just coughed up a one line pax_global_header file :
|
|52 comment=97ace46e11dba4c4c2b7cb67140b6ec152cfaaf4
|
|> We had a similar discussion after 1.1.1b was released, it started here
|> https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html
|>
|> see in particular reply
|> https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html
|>
|> and the links to the LKML which it contains
|> https://lkml.org/lkml/2005/6/18/5
|> https://marc.info/?l=linux-kernel&m=111909182607985&w=2
|
|Perfectly harmless feature. Thank you for the detailed reply.
Does not look harmless on some BSD unless thorougly inspected
iirc. Since 2013-09-13 ([9c1375a7]) i thus repack balls
# Repack with standard tar(1) to avoid new-style headers
${git} archive --format=tar --prefix="${PROGRAM}-${REL}/" v${REL}.ar |
( cd "${TMPDIR}" && ${tar} -x -f - )
cd "${TMPDIR}"
${tar} -c -f "${PROGRAM}-${REL}.tar" "${PROGRAM}-${REL}"
NetBSD tar for example might say[1], which is frightening.
"%s extended headers posix ustar archive."
" Extracting as plain files. Following files might be"
" in the wrong directory or have wrong attributes.",
[1]
http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/pax/tar.c?rev=1.75&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: AW: Slightly funny tar ball for openssl 1.1.1c ?
beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - tar: pax_global_header: typeflag 'g' not recognized, converting to regular file beta $ Must be a gnu tar thing? Hi Dennis, it's not a bug, it's a feature. ;-) No seriously: it's the `git archive` command which is used to export the tree into a tarfile. It adds an extended header containing the commit hash of the commit which was exported. Older tar programs don't know how to deal with that header and are a bit confused about it. Yep. Old POSIX tar just coughed up a one line pax_global_header file : 52 comment=97ace46e11dba4c4c2b7cb67140b6ec152cfaaf4 We had a similar discussion after 1.1.1b was released, it started here https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html see in particular reply https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html and the links to the LKML which it contains https://lkml.org/lkml/2005/6/18/5 https://marc.info/?l=linux-kernel&m=111909182607985&w=2 Perfectly harmless feature. Thank you for the detailed reply. Dennis
AW: Slightly funny tar ball for openssl 1.1.1c ?
> -Ursprüngliche Nachricht- > I don't thing I have seen this before : > > beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - > tar: pax_global_header: typeflag 'g' not recognized, converting to > regular file > beta $ > > Must be a gnu tar thing? Hi Dennis, it's not a bug, it's a feature. ;-) No seriously: it's the `git archive` command which is used to export the tree into a tarfile. It adds an extended header containing the commit hash of the commit which was exported. Older tar programs don't know how to deal with that header and are a bit confused about it. We had a similar discussion after 1.1.1b was released, it started here https://mta.openssl.org/pipermail/openssl-users/2019-February/009936.html see in particular reply https://mta.openssl.org/pipermail/openssl-users/2019-February/009949.html and the links to the LKML which it contains https://lkml.org/lkml/2005/6/18/5 https://marc.info/?l=linux-kernel&m=111909182607985&w=2 HTH, Matthias
Slightly funny tar ball for openssl 1.1.1c ?
I don't thing I have seen this before : beta $ gzip -dc ../src/openssl-1.1.1c.tar.gz | tar -xf - tar: pax_global_header: typeflag 'g' not recognized, converting to regular file beta $ Must be a gnu tar thing? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Performance Issue With OpenSSL 1.1.1c
I built OpenSSL 1.1.1c from the recent release, but have noticed what seems like a significant performance drop compared with 1.1.1b. I notice this when starting lighttpd. With 1.1.1b, lighttpd starts in a few seconds, but with 1.1.1c, it takes several minutes. I also noticed that with 1.1.1b, the CFLAGS automatically included '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the CFLAGS. was this dropped? I added '-Wall -O3' to the CFLAGS, but this did not seem to have any affect on the performance issue (unrelated?). This is for a 32-bit ARM build. Jay
RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Chethan Kumar > Sent: Tuesday, May 28, 2019 08:49 > > I meant to say linking to both by doing ldd. > When ldd is done on application, both libcrypto.so.1.0.0 and libcrypto.1.1 is > shown. Don't tell us about the ldd output. Show us. ldd output is short enough to include in an email message. > > Is it using some kind of dynamic module that happens to be linked with an > older OpenSSL version? > No, its not using any dynamic module. This is obviously incorrect. You've already noted that it's loading at least three - the two versions of libcrypto and libssl. Your application may not be doing any explicit dynamic loading, but it has implicit dynamic loads. That's what ldd shows. You haven't shown us the link line for the application. -- Michael Wojcik Distinguished Engineer, Micro Focus
RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
I meant to say linking to both by doing ldd. When ldd is done on application, both libcrypto.so.1.0.0 and libcrypto.1.1 is shown. Here libcrypto.so.1.0.0 is taken from the one provided by OS. > Is it using some kind of dynamic module that happens to be linked with an > older OpenSSL version? No, its not using any dynamic module. Its built on platform: Linux version 4.4.130-cip23-eBN-kernel (jenkins@skelios-plt) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) ) -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Richard Levitte Sent: Tuesday, May 28, 2019 7:37 PM To: openssl-users@openssl.org Subject: Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 In what way does it link to both? What output do you get when running 'ldd' in your application? Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version? Cheers, Richard On Tue, 28 May 2019 06:59:27 +0200, Chethan Kumar wrote: > > > Dear all, > > Any help for the below query would be appreciated. > > Thanks in advance, > > Chethan Kumar > > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Chethan Kumar > Sent: Wednesday, May 22, 2019 11:35 AM > To: openssl-users@openssl.org > Subject: Application linking to both libcrypto.so.1.0.0 and > libcrypto.so.1.1 > > Dear all, > > While migrating from openssl 1.0.2n to openssl 1.1.1b, application > which uses openssl was compiling against openssl 1.1.1b. > > Compilation is fine but its linking to both libcrypto.so.1.0.0[from > /usr/lib/] and libcrypto.so.1.1. > > Its linking correctly to libssl.1.1. > > Is this correct? If so, what could be the possible reason. > > Thanks in advance, > > Chethan Kumar > > The information contained in this e-mail message and in any > attachments/annexure/appendices is confidential to the recipient and > may contain privileged information. If you are not the intended > recipient, please notify the sender and delete the message along with > any attachments/annexure/appendices. You should not disclose, copy or > otherwise use the information contained in the message or any > annexure. Any views expressed in this e-mail are those of the > individual sender except where the sender specifically states them to > be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free > of any virus or other defect that might affect any computer system > into which it is received and opened, it is the responsibility of the > recipient to ensure that it is virus free and no responsibility is accepted > by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way > from its use. > > The information contained in this e-mail message and in any > attachments/annexure/appendices is confidential to the recipient and > may contain privileged information. If you are not the intended > recipient, please notify the sender and delete the message along with > any attachments/annexure/appendices. You should not disclose, copy or > otherwise use the information contained in the message or any > annexure. Any views expressed in this e-mail are those of the > individual sender except where the sender specifically states them to > be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free > of any virus or other defect that might affect any computer system > into which it is received and opened, it is the responsibility of the > recipient to ensure that it is virus free and no responsibility is accepted > by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way > from its use. > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1
In what way does it link to both? What output do you get when running 'ldd' in your application? Is it using some kind of dynamic module that happens to be linked with an older OpenSSL version? Cheers, Richard On Tue, 28 May 2019 06:59:27 +0200, Chethan Kumar wrote: > > > Dear all, > > Any help for the below query would be appreciated. > > Thanks in advance, > > Chethan Kumar > > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Chethan Kumar > Sent: Wednesday, May 22, 2019 11:35 AM > To: openssl-users@openssl.org > Subject: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1 > > Dear all, > > While migrating from openssl 1.0.2n to openssl 1.1.1b, application which uses > openssl was > compiling against openssl 1.1.1b. > > Compilation is fine but its linking to both libcrypto.so.1.0.0[from > /usr/lib/] and > libcrypto.so.1.1. > > Its linking correctly to libssl.1.1. > > Is this correct? If so, what could be the possible reason. > > Thanks in advance, > > Chethan Kumar > > The information contained in this e-mail message and in any > attachments/annexure/appendices is > confidential to the > recipient and may contain privileged information. If you are not the intended > recipient, please > notify the > sender and delete the message along with any attachments/annexure/appendices. > You should not > disclose, > copy or otherwise use the information contained in the message or any > annexure. Any views > expressed in this e-mail > are those of the individual sender except where the sender specifically > states them to be the > views of > Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free of any > virus or other > defect that might affect any computer system into which it is received and > opened, it is the > responsibility of the recipient to ensure that it is virus free and no > responsibility is accepted > by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way > from its use. > > The information contained in this e-mail message and in any > attachments/annexure/appendices is > confidential to the > recipient and may contain privileged information. If you are not the intended > recipient, please > notify the > sender and delete the message along with any attachments/annexure/appendices. > You should not > disclose, > copy or otherwise use the information contained in the message or any > annexure. Any views > expressed in this e-mail > are those of the individual sender except where the sender specifically > states them to be the > views of > Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > Although this transmission and any attachments are believed to be free of any > virus or other > defect that might affect any computer system into which it is received and > opened, it is the > responsibility of the recipient to ensure that it is virus free and no > responsibility is accepted > by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way > from its use. > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
OpenSSL version 1.1.1c published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 1.1.1c released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1c of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1c is available for download via HTTP 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-1.1.1c.tar.gz Size: 8864262 SHA1 checksum: 71b830a077276cbeccc994369538617a21bee808 SHA256 checksum: f6fb3079ad15076154eda9413fed42877d668e7069d9b87396d0804fdb3f4c90 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1c.tar.gz openssl sha256 openssl-1.1.1c.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztM8MACgkQ1enkP335 7ow2lRAAirwJYIX4XunYXMV88tQILxAB6iCDiN04c5r5ayJqmF5Zr3QKGDG7Vj+l q6NEmKIYpyjAxZau3orl0OC5L4Us+URFpyFpCe8BOpXjasFQYk7jycr3MI1BHYcO dl9gVx09BZriR+q9w5xBJad34leCvuCD950+9eG/DY3+xSSWLDeagzz+dhOgTnOj +YyMo+o/f+VucjsYddL2ehL5v744xdqu6Pu4JMceLaRdSfmKXRqwlob2w2UtCgoD roy4+pPVLA9FYBOOYy1n2PFGopp/c67xfQX1yB35mjAB5y3FSJAWFS0gvPaHvzj1 D+zbQSxYVksOyUSrK33KnJmouaml5+CQgYRS+Umn8549A2apkIB/yRLo2K65Iuqd KHgZGbI4cGUBEdbIxUDtvhsIr/+JlujJPvs5Eyiwm8+K/WPiZ3Hw8EXmdqTl9ITK 7URwWM4thq1sikD7RKHl4h9gEzvB6iqTd+dPbUE8jIc29HD7rPJWCw3m+gOGEoAu L0rU4palNa1Ab6kMZ2SYsXv/rH4pl0iHBBrzVOStay/k4zPYS3eD6kytyB0vLt6g f0u4heD4G4QiohqIFaDHjs8eSq1Paz3eA3Ylly8JKweBFTrHHssyz22ItGDCcQwz cOb7H3o/AdXGZOSHxHtLBQqxsUcCuUID0YTyUB43bRuLnVmWs6I= =EHRv -END PGP SIGNATURE-
OpenSSL version 1.1.0k published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 1.1.0k released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0k of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0k is available for download via HTTP 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-1.1.0k.tar.gz Size: 5287321 SHA1 checksum: aaa2ddad0285575da7c9fa8021c26e5c8433ab15 SHA256 checksum: efa4965f4f773574d6cbda1cf874dbbe455ab1c0d4f906115f867d3070b1 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0k.tar.gz openssl sha256 openssl-1.1.0k.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMKgACgkQ1enkP335 7ozB7BAArso7v+Yy6+3TiPPaH+EAYkEr2J+WQ2D17s7M9kpW8errvyX7B/yMIVSh 1ZEPfWWtmDdd9CDqfpM/P2ttipjHvrPvwh01+Re8sm+pE8me3j9N1UkqXLpRPQuW eSAwjSYcVTgGlDlJnsDW7Yxf1vibfjA7hDHL+7MY3tdPna2rb2TICOmX1TmwR4ha Xc6E6JAH049Rjzh9NCgcxANnembTnPqRAVmxyf6ziMmvHeDe6voYQZrtagC1CHbY x1Y+Q3GMLtvebm7YRqoy3o29WFMPUPErcfPsun9aizmTR+UgePjQ9Tjq6bF9umTL 5Z1lt4JJsC0gUmKLTpPL0SNhAf1/TS59Usvk4pMefSq7ejteSzX1xoHY/VQ4U8pO pO8Vsn7k8U4azuRgi3diprYhgtMDeK4udyepFTI53Bqk/H7Gm0v+R7tYYH2Zbwqm 49UuvMlP/7XHKwo0hIoV6Ul3xrNprxoXQmTG+Tm4+AoA4Qn9jELvMe96CaeLAPxG V7NjqK7Tr4Iosso4h+Pq2oEsu3GLzXVdFYA5RORkakuX60Y8+jznKAP4WNhPS/rs zPr8fVghb0kpctodvq2px47DVQSsUf2nYGVwu205bHpGyTKuB1ZWkYbC6cQEg3yB SPlFyHmHWYjqk8RSmSKZSiN33x0ysG8kwr3PEJOEEe8bvF3r7cM= =go9J -END PGP SIGNATURE-
OpenSSL version 1.0.2s published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 1.0.2s released === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2s of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2s is available for download via HTTP 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-1.0.2s.tar.gz Size: 5349149 SHA1 checksum: cf43d57a21e4baf420b3628677ebf1723ed53bc1 SHA256 checksum: cabd5c9492825ce5bd23f3c3aeed6a97f8142f606d893df216411f07d1abab96 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2s.tar.gz openssl sha256 openssl-1.0.2s.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMAcACgkQ1enkP335 7ozPdRAAnUKK6jxlMa3O2GeVDU0ZZNS3A3zyMJd2yPCB3I3b0BMxy/ZWw4A6Vtyd l1M+GhP7/SG+kom9f6Ky2QXTW29lYQT4ImNZwU/hRI/nLKCqFw9Kzq4wqZnwlavx pI54Loz86Ysp2PIAtWJrOPxWT7HEculhhR0yOXxWAlAkRmrbrG3JdTba3UIH0T2P 3xoncvI0ODXWE6eW3hNCtxb/npo/czcAolO/EEN60tRcZm849ODgzNqpiV5zegoF cogfVaQFGcOncv4bYdxQIPBDBLWVEEkT+05agnFfZkv6hpIL8h2jrG4b46ULs+ZM 4iNznwLEVNVhF6Qm6RIffC3xrKIhmDZkGH8Y/ypBOTVk/vUhvot+a7Ab05fvnqeR O5BwxUVwNsxQdZ4v4BKJM/RE1ApHuQoezOCwfPfMT2NZd3StVueQxkwSrRhtEx8k ZnRrgtqYM8zCjqW7uVOvSIB08EZvJpIhMofIMqlfEixdTvmSvHQ8iPCQrKS0dmjA CtWdSgFbc7NYXwj5lqfr58brKhhoap/B8MFvVaGkcqhsCp5pE/a8JO79ESI7TVQD uxs28qhEj7RXNH61m9viOvu75ph6lfVxI/4Hat7yi/pzr4jpYYJXWM6Iz9PTf2PS admaUdGLOUB7L51Z7/uTHuACV16SwXryJn4b0OwuTmUQ9rsdDRA= =aI2x -END PGP SIGNATURE-
