Re: Reg missing rc4-ia64.pl in openssl 1.1.1

[ramakrushna mishra]

Hi,

Thanks for all the information related to missing rc4 assembly file for
IA-64 architecture.

*Richard : * The following mentioned degradation on nt64 compared to the
same openssl version 1.1.1 build with out using the flags "
"enable-weak-ssl-ciphers" and "
 enable-deprecated" .

Thanks and Regards,
Ram Krushna


> Similarly If I build Openssl 1.1.1 on nt64? with flags
> "enable-weak-ssl-ciphers" and "
> > enable-deprecated"? , I witness degrade in performance.? Could you
> please help me understand how
> > these flags can be related to speed test of all ciphers and digests ??
>
> Degradation, compared to what?
>
> Cheers,
> Richard
>
> End of openssl-users Digest, Vol 54, Issue 49
> *
>

AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

Correction, Tomáš was correct: there is an ` # ifndef DEVRANDOM` surrounding
the problematic code:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L25-L34

Neverthelesss, I still think this code needs to be changed, because the seeding
should just work correctly out-of-the-box without having to add special
defines on the commandline.

Matthias

RE: Reg missing rc4-ia64.pl in openssl 1.1.1

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> J. J. Farrell
> Sent: Wednesday, May 29, 2019 15:02

> On 29/05/2019 18:39, ramakrushna mishra wrote:

>> In Openssl 1.1.1,  the file "rc4-ia64.pl" is missing. This cause degradation 
>> of
>> performance on AIX. ...

> The AIX port to Itanium was never released as a product, and was abandoned
> altogether in 2002; I'm surprised that a degradation of performance on it
> matters to anyone.

What, no love for unobtainable archaic platforms?

Personally, I'm bemoaning the lack of a rc4-romp.pl for AIX 2 on my RT PC. And 
the shocking lack of assembly modules for the PDP-11.

In all seriousness: It's pretty cool that OpenSSL still includes assembly 
modules for what are now rather niche architectures such as MIPS and PA-RISC. 
And in case all this is too convoluted for the OP, rc4-ia64.pl doesn't apply to 
extant AIX systems, which are all some variant of POWER, not IA64.

(OK, somewhere someone probably has one of the other AIX variants running - 
AIX/390 might be the last non-POWER AIX to die, if I had to bet. But probably 
not AIX IA64.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus

AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

> To workaround the /dev/random blocking issue, you can just add:
> 
> -DDEVRANDOM="\"/dev/urandom\""
> 
> as a parameter to ./Configure
> 
> This will remove the special handling of /dev/urandom and /dev/random
> in 1.1.1c.


Tomáš, Jay,

I'm afraid this suggestion won't help, because `DEVRANDOM_WAIT` is defined
unconditionally in e_os.h:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L30-L34

This means that the select() call will happen on linux independently of what
`DEVRANDOM` is defined to be:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/crypto/rand/rand_unix.c#L509-L535

I think that pull request #8251 needs to be reconsidered. Give me one day or 
two, 
I'll create a GitHub issue for that and post the link here when it's ready.

Matthias

Re: Reg missing rc4-ia64.pl in openssl 1.1.1

[J. J. Farrell]

On 29/05/2019 18:39, ramakrushna mishra wrote:


In Openssl 1.1.1,  the file "rc4-ia64.pl " is 
missing. This cause degradation of performance on AIX. ...


The AIX port to Itanium was never released as a product, and was 
abandoned altogether in 2002; I'm surprised that a degradation of 
performance on it matters to anyone.


--
J. J. Farrell
Not speaking for Oracle

Re: Reg missing rc4-ia64.pl in openssl 1.1.1

[Richard Levitte]

On Wed, 29 May 2019 19:39:38 +0200,
ramakrushna mishra wrote:
> In Openssl 1.1.1,  the file "rc4-ia64.pl" is missing. This cause degradation 
> of performance on
> AIX.  Is this intentional for deprecating the support for RC4 ? 

It got remove as part of a larger cleanup commit:

commit 624265c60e07f8e5f251d0f5b79e34cf0221af73
Author: Rich Salz 
Date:   Thu Jun 15 12:03:40 2017 -0400

Cleanup some copyright stuff

Remove some incorrect copyright references.
Move copyright to standard place
Add OpenSSL copyright where missing.
Remove copyrighted file that we don't use any more
Remove Itanium assembler for RC4 and MD5 (assembler versions of old and
weak algorithms for an old chip)
Standardize apps/rehash copyright comment; approved by Timo
Put dual-copyright notice on mkcert

Reviewed-by: Richard Levitte 
(Merged from https://github.com/openssl/openssl/pull/3691)

> Similarly If I build Openssl 1.1.1 on nt64  with flags 
> "enable-weak-ssl-ciphers" and "
> enable-deprecated"  , I witness degrade in performance.  Could you please 
> help me understand how
> these flags can be related to speed test of all ciphers and digests ? 

Degradation, compared to what?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: X509_STORE_CTX_get1_certs

[Viktor Dukhovni]

On Wed, May 29, 2019 at 07:44:26PM +, Jason Schultz wrote:

> It looks like this function is available in OpenSSL 1.1.1 (not available
> in 1.0.2) and I think I need to use it, but I can't find documentation for
> it anywhere.

In 1.0.2 it was called X509_STORE_get1_certs().

> Is this an over site, or am I missing something obvious?

It has not yet been documented.

-- 
Viktor.

X509_STORE_CTX_get1_certs

[Jason Schultz]

It looks like this function is available in OpenSSL 1.1.1 (not available in 
1.0.2) and I think I need to use it, but I can't find documentation for it 
anywhere.

Is this an over site, or am I missing something obvious?

Thanks,

Jason

Re: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

[Michael Richardson]

Chethan Kumar  wrote:
> Sorry for the inconvenience caused by not asking query clearly.
> Below is the output from ldd on application.

Right, and now you need to recursively go through the list with readelf or
ldd, and which out which one of these libraries then requires
libcrypto.1.0.0.
My bet is on some of the krb libraries, likely required by sqlite or
perhaps something else like this libCryptolib.so.0.
Also, run your application, and use "lsof -p PID" to see the list of
libraries loaded as some dependancies may be done at runtime by dlopen().


--
]   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

[Viktor Dukhovni]

> On May 29, 2019, at 9:43 AM, Michael Wojcik  
> wrote:
> 
> So either the application program depends on libcrypto.so.1.0.0, or one of 
> the preceding libraries does. Some path through the dependency graph leads to 
> libcrypto.so.1.0.0.

Not only is the application (dynamically) linked against two different
versions of OpenSSL's crypto library, it is also using both Heimdal and
MIT Kerberos, which may also cause some confusion if symbol versioning
does not fully take care of the overlapping APIs.

> Kerberos seems like a candidate, but a quick ldd on libk5crypto and 
> libkrb5support doesn't show any libcrypto dependency. The same is true of 
> libgssapi_krb5. Neither does libkeyutils.

Heimdal might be linked against OpenSSL.

> OpenLDAP (libldap) is generally built using NSS rather than OpenSSL, so it 
> doesn't usually link libcrypto.

It is also often built against OpenSSL, the choice is rather platform-dependent.

This application is a classic case of DLL-hell.  On the OpenSSL side, it could
benefit from the "shlib_variant" feature of the 1.1.1 builds.  But if the base
system's OpenSSL libraries are adequate, the OP may be better off just using
those.

-- 
Viktor.

Reg missing rc4-ia64.pl in openssl 1.1.1

[ramakrushna mishra]

Hi,

In Openssl 1.1.1,  the file "rc4-ia64.pl" is missing. This cause
degradation of performance on AIX.  Is this intentional for deprecating the
support for RC4 ?

Similarly If I build Openssl 1.1.1 on nt64  with flags
"*enable-weak-ssl-ciphers"
and "**enable-deprecated"  , *I witness degrade in performance.  Could you
please help me understand how these flags can be related to speed test of
all ciphers and digests ?

Thanks and Regards,
Ram Krushna

Re: Performance Issue With OpenSSL 1.1.1c

[Tomas Mraz]

On Tue, 2019-05-28 at 10:39 -0700, 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.

To workaround the /dev/random blocking issue, you can just add:

-DDEVRANDOM="\"/dev/urandom\""

as a parameter to ./Configure

This will remove the special handling of /dev/urandom and /dev/random
in 1.1.1c.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

Re: Forthcoming OpenSSL Releases

[Matthias St. Pierre]

On 29.05.19 15:05, The Doctor wrote:

For the next branch of OpenSSL is it 1.1.2 or 1.2.0 ?



The next major release will be 3.0.0. See
https://www.openssl.org/blog/blog/2018/11/28/version 

for an explanation.

Matthias

Re: Performance Issue With OpenSSL 1.1.1c

[Steffen Nurpmeso]

Jakob Bohm via openssl-users wrote in <23f8b94d-0078-af3c-b46a-929b9d005\
4...@wisemo.com>:
 |On 28/05/2019 23:48, Steffen Nurpmeso wrote:
 |> 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 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.

P.S.: i have now looked at the OpenSSL code and understand what
you have said.  It indeed selects on /dev/random.

 |> 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.

 |Something equivalent to your program (but not storing a bitcount field)
 |used to be standard in Linux boot scripts before systemd.  But it
 |typically used the old method of just writing the saved random bits
 |into /dev/{u,}random .

Oh, still, for example AlpineLinux did (and still does i think,
using a script originating from Gentoo aka OpenRC) save a kilobyte
of /dev/urandom storage, to restore it upon next boot.  But it
does not feed the pool which feds /dev/random, it does not count
against /proc/sys/kernel/random/entropy_avail.

Even that i can understand a little bit (physical access would
reveal data stored in the entropy file), even though the entropy
is not used but passed through state machines, which could be
furtherly randomized when fed back in, like also dependent on the
host hardware environment interrupts which happen and depend on
actual devices i'd say, and while doing so.

But you loose all the entropy that the machine collected during
its last uptime, so you solely depend on some CPU features and the
noise that system startup produces to create a startup entropy.
After running in the problem and looking around i realized that
many people seem to run the haveged daemon (there is also a kernel
module which does something like this, but using it did not help
me out), which applies some maths, and it is mystic as it can
produce thousands of random bits in less than a second!

Even on my brand new laptop, which (stepped a decade of hardware
development for me and) has a 8th generation i5, i see hangs of
several seconds (iirc) without the little helper i attached in the
last message.  With it i have a (SysV init/BSD rc script aka
CRUX-Linux) boot time of two seconds, which is so horny i have to
write it down.

 |This makes me very surprised that they removed such a widely used
 |interface, can you point out when that was removed from the Linux
 |kernel?

Hm, ok, what they have actually removed was the RNDGETPOOL
ioctl(2) (according to random(4)).  Then my claim regarding
deprecation was misleaded and wrong.

Nonetheless it has to be said that today an administrator does not
have, that is, i have no idea whether systemd provides something
to overcome this, the possibility to simply feed in good entropy
via a shell script, unless i am mistaken.

--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: Performance Issue With OpenSSL 1.1.1c

[Jakob Bohm via openssl-users]

On 28/05/2019 23:48, Steffen Nurpmeso wrote:

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.

Something equivalent to your program (but not storing a bitcount field)
used to be standard in Linux boot scripts before systemd.  But it
typically used the old method of just writing the saved random bits
into /dev/{u,}random .

This makes me very surprised that they removed such a widely used
interface, can you point out when that was removed from the Linux
kernel?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Fw: Building openssl outside of the source tree" doesn't work well

[dengwenbin_0301]

Please help have a look.


| |
dengwenbin_0301
邮箱：dengwenbin_0...@126.com
|

Signature is customized by Netease Mail Master

- Forwarded Message -

From: dengwenbin_0301
Date: 05/27/2019 14:24
To: Richard Levitte
Subject: Re:Re: Fw:Re:Re: Building openssl outside of the source tree" doesn't 
work well
Sorry, the previously attached dump might too large to send out successfully. I 
copied it directly here.

Command line (with current working directory = .):

/usr/bin/perl ../Configure linux-x86_64

Perl information:

/usr/bin/perl
5.22.1 for x86_64-linux-gnu-thread-multi

Enabled features:

afalgeng
aria
asm
async
autoalginit
autoerrinit
autoload-config
bf
blake2
camellia
capieng
cast
chacha
cmac
cms
comp
crmf
ct
deprecated
des
dgram
dh
dsa
dtls
dynamic-engine
ec
ec2m
ecdh
ecdsa
engine
err
filenames
fips
gost
idea
legacy
makedepend
md4
mdc2
module
multiblock
nextprotoneg
pinshared
ocb
ocsp
padlockeng
pic
poly1305
posix-io
psk
rc2
rc4
rdrand
rfc3779
rmd160
scrypt
seed
shared
siphash
siv
sm2
sm3
sm4
sock
srp
srtp
sse2
ssl
static-engine
stdio
tests
threads
tls
ts
ui-console
whirlpool
tls1
tls1-method
tls1_1
tls1_1-method
tls1_2
tls1_2-method
tls1_3
dtls1
dtls1-method
dtls1_2
dtls1_2-method

Disabled features:

ktls[default] OPENSSL_NO_KTLS
asan[default] OPENSSL_NO_ASAN
buildtest-c++   [default]
crypto-mdebug   [default] OPENSSL_NO_CRYPTO_MDEBUG
crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
devcryptoeng[default] OPENSSL_NO_DEVCRYPTOENG
ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
egd [default] OPENSSL_NO_EGD
external-tests  [default] OPENSSL_NO_EXTERNAL_TESTS
fuzz-libfuzzer  [default] OPENSSL_NO_FUZZ_LIBFUZZER
fuzz-afl[default] OPENSSL_NO_FUZZ_AFL
md2 [default] OPENSSL_NO_MD2 (skip crypto/md2)
msan[default] OPENSSL_NO_MSAN
rc5 [default] OPENSSL_NO_RC5 (skip crypto/rc5)
sctp[default] OPENSSL_NO_SCTP
ssl-trace   [default] OPENSSL_NO_SSL_TRACE
trace   [default] OPENSSL_NO_TRACE
ubsan   [default] OPENSSL_NO_UBSAN
unit-test   [default] OPENSSL_NO_UNIT_TEST
weak-ssl-ciphers[default] OPENSSL_NO_WEAK_SSL_CIPHERS
zlib[default]
zlib-dynamic[default]
ssl3[default] OPENSSL_NO_SSL3
ssl3-method [default] OPENSSL_NO_SSL3_METHOD

Config target attributes:

AR => "ar",
ARFLAGS => "r",
CC => "gcc",
CFLAGS => "-Wall -O3",
CXX => "g++",
CXXFLAGS => "-Wall -O3",
HASHBANGPERL => "/usr/bin/env perl",
RANLIB => "ranlib",
RC => "windres",
aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s aesni-x86_64.s 
aesni-sha1-x86_64.s aesni-sha256-x86_64.s aesni-mb-x86_64.s",
aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o 
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o",
apps_aux_src => "",
apps_init_src => "",
apps_obj => "",
bf_asm_src => "bf_enc.c",
bf_obj => "bf_enc.o",
bn_asm_src => "asm/x86_64-gcc.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s 
rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
bn_obj => "asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o 
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
bn_ops => "SIXTY_FOUR_BIT_LONG",
build_file => "Makefile",
build_scheme => [ "unified", "unix" ],
cast_asm_src => "c_enc.c",
cast_obj => "c_enc.o",
cflags => "-pthread -m64",
chacha_asm_src => "chacha-x86_64.s",
chacha_obj => "chacha-x86_64.o",
cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
cmll_obj => "cmll-x86_64.o cmll_misc.o",
cppflags => "",
cpuid_asm_src => "x86_64cpuid.s",
cpuid_obj => "x86_64cpuid.o",
cxxflags => "-std=c++11 -pthread -m64",
defines => [  ],
des_asm_src => "des_enc.c fcrypt_b.c",
des_obj => "des_enc.o fcrypt_b.o",
disable => [  ],
dso_ldflags => "-z defs",
dso_scheme => "dlfcn",
ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
enable => [ "afalgeng" ],
ex_libs => "-ldl -pthread",
includes => [  ],
keccak1600_asm_src => "keccak1600-x86_64.s",
keccak1600_obj => "keccak1600-x86_64.o",
lflags => "",
lib_cflags => "",
lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN",
lib_defines => [  ],

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

[Michael Wojcik]

> From: Chethan Kumar [mailto:chethan.ku...@toshiba-tsip.com]
> Sent: Wednesday, May 29, 2019 04:07
>
> Below is the output from ldd on application.
> Seriously I didn't knew application uses these many libraries[Knew only the
> problem].
> linux-gate.so.1 (0xf76fc000)
> libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf6a63000)
> libldap-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/libldap-
> 2.4.so.2 (0xf6a29000)
> libssl.so.1.1 => /home/SYSROM_SRC/build/release/lib/libssl.so.1.1
> (0xf699)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6972000)
> libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0
> (0xf689c000)
> libcrypto.so.1.1 =>
> /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1 (0xf65af000)
> libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3
> (0xf657e000)
> libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6566000)
> libext2fs.so.2 => /lib/i386-linux-gnu/libext2fs.so.2 (0xf6516000)
> libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6511000)
> libdns.so.69 => /home/SYSROM_SRC/build/release/lib/libdns.so.69
> (0xf635c000)
> libisc.so.62 => /home/SYSROM_SRC/build/release/lib/libisc.so.62
> (0xf62e7000)
> librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf62de000)
> libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0
> (0xf62d2000)
> libkrb5.so.25 => /home/SYSROM_SRC/build/release/lib/libkrb5.so.25
> (0xf6259000)
> libgssapi.so.2 => /home/SYSROM_SRC/build/release/lib/libgssapi.so.2
> (0xf6222000)
> libCryptolib.so.0 =>
> /home/SYSROM_SRC/build/release/lib/libCryptolib.so.0 (0xf6191000)
> libimf.so => /mfp/lib/libimf.so (0xf5dd8000)
> libirng.so => /usr/lib/libirng.so (0xf5c6e000)
> libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf5c1a000)
> libcilkrts.so.5 => /usr/lib/libcilkrts.so.5 (0xf5bec000)
> libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf5afd000)
> libsvml.so => /mfp/lib/libsvml.so (0xf4bbf000)
> libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf4bab000)
> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf4ba6000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf49e4000)
> liblber-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/liblber-
> 2.4.so.2 (0xf49d9000)
> libsasl2.so.3 => /home/SYSROM_SRC/build/release/lib/libsasl2.so.3
> (0xf49a4000)
> /lib/i386-linux-gnu/ld-linux.so.2 (0xf76fd000)
> libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf49a)
> libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf499b000)
> libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2
> (0xf494c000)
> libcom_err.so.1 => /home/SYSROM_SRC/build/release/lib/libcom_err.so.1
> (0xf4948000)
> libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0
> (0xf476b000)

So either the application program depends on libcrypto.so.1.0.0, or one of the 
preceding libraries does. Some path through the dependency graph leads to 
libcrypto.so.1.0.0.

>From the readelf output below, we see it's not the application program - that 
>only depends on libcrypto.so.1.1. So it's one of the preceding libraries. 
>There's a good chance it's one that comes from the OS library collection 
>rather than a library you've built (though that's by no means certain), so 
>let's focus on ones that aren't under /home/SYSROM_SRC.

Kerberos seems like a candidate, but a quick ldd on libk5crypto and 
libkrb5support doesn't show any libcrypto dependency. The same is true of 
libgssapi_krb5. Neither does libkeyutils.

OpenLDAP (libldap) is generally built using NSS rather than OpenSSL, so it 
doesn't usually link libcrypto.

None of the other OS libraries above look particularly likely to use libcrypto. 
So I'd suggest you use ldd on each of the libraries listed above to find out 
which is giving you the dependency on libcrypto.so.1.0.0. Or use LD_DEBUG to 
generate a loader report for your application, and work backward from that.

Writing a script to use readelf to generate a dependency graph report showing 
the path for each dependency is left as an exercise for the reader.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: Forthcoming OpenSSL Releases

[The Doctor]

For the next branch of OpenSSL is it 1.1.2 or 1.2.0 ?

-- 
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  Look at Psalms 14 and 53 on Atheism
Always seek out the seed of triumph in every adversity.  -Og Mandino

Re: Forthcoming OpenSSL Releases

[Matt Caswell]

On 21/05/2019 16:43, Matt Caswell wrote:
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s.
> 
> These releases will be made available on 28th May 2019 between approximately
> 1200-1600 UTC.
> 
> OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not
> address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the
> equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant).

Correction to this announcement: OpenSSL 1.1.1c and OpenSSL 1.1.0k (released
yesterday) do not address any new CVEs. They do however contain a fix for a
previously announced low severity CVE (CVE-2019-1543). See the original security
advisory here:

https://www.openssl.org/news/secadv/20190306.txt

Matt



signature.asc
Description: OpenPGP digital signature

RE: Application linking to both libcrypto.so.1.0.0 and libcrypto.so.1.1

[Chethan Kumar]

Dear all,

Sorry for the inconvenience caused by not asking query clearly.
Below is the output from ldd on application.
Seriously I didn't knew application uses these many libraries[Knew only the 
problem].
linux-gate.so.1 (0xf76fc000)
libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf6a63000)
libldap-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/libldap-2.4.so.2 
(0xf6a29000)
libssl.so.1.1 => /home/SYSROM_SRC/build/release/lib/libssl.so.1.1 
(0xf699)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf6972000)
libsqlite3.so.0 => /usr/lib/i386-linux-gnu/libsqlite3.so.0 (0xf689c000)
libcrypto.so.1.1 => /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.1 
(0xf65af000)
libk5crypto.so.3 => /usr/lib/i386-linux-gnu/libk5crypto.so.3 
(0xf657e000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf6566000)
libext2fs.so.2 => /lib/i386-linux-gnu/libext2fs.so.2 (0xf6516000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf6511000)
libdns.so.69 => /home/SYSROM_SRC/build/release/lib/libdns.so.69 
(0xf635c000)
libisc.so.62 => /home/SYSROM_SRC/build/release/lib/libisc.so.62 
(0xf62e7000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf62de000)
libkrb5support.so.0 => /usr/lib/i386-linux-gnu/libkrb5support.so.0 
(0xf62d2000)
libkrb5.so.25 => /home/SYSROM_SRC/build/release/lib/libkrb5.so.25 
(0xf6259000)
libgssapi.so.2 => /home/SYSROM_SRC/build/release/lib/libgssapi.so.2 
(0xf6222000)
libCryptolib.so.0 => 
/home/SYSROM_SRC/build/release/lib/libCryptolib.so.0 (0xf6191000)
libimf.so => /mfp/lib/libimf.so (0xf5dd8000)
libirng.so => /usr/lib/libirng.so (0xf5c6e000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf5c1a000)
libcilkrts.so.5 => /usr/lib/libcilkrts.so.5 (0xf5bec000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf5afd000)
libsvml.so => /mfp/lib/libsvml.so (0xf4bbf000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf4bab000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf4ba6000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf49e4000)
liblber-2.4.so.2 => /home/SYSROM_SRC/build/release/lib/liblber-2.4.so.2 
(0xf49d9000)
libsasl2.so.3 => /home/SYSROM_SRC/build/release/lib/libsasl2.so.3 
(0xf49a4000)
/lib/i386-linux-gnu/ld-linux.so.2 (0xf76fd000)
libkeyutils.so.1 => /lib/i386-linux-gnu/libkeyutils.so.1 (0xf49a)
libcom_err.so.2 => /lib/i386-linux-gnu/libcom_err.so.2 (0xf499b000)
libgssapi_krb5.so.2 => /usr/lib/i386-linux-gnu/libgssapi_krb5.so.2 
(0xf494c000)
libcom_err.so.1 => /home/SYSROM_SRC/build/release/lib/libcom_err.so.1 
(0xf4948000)
libcrypto.so.1.0.0 => /usr/lib/i386-linux-gnu/libcrypto.so.1.0.0 
(0xf476b000)
libcap.so.2 => /lib/i386-linux-gnu/libcap.so.2 (0xf4766000)
libhx509.so.5 => /home/SYSROM_SRC/build/release/lib/libhx509.so.5 
(0xf472)
libheimsqlite.so.0 => 
/home/SYSROM_SRC/build/release/lib/libheimsqlite.so.0 (0xf46a9000)
libhcrypto.so.4 => /home/SYSROM_SRC/build/release/lib/libhcrypto.so.4 
(0xf4673000)
libasn1.so.8 => /home/SYSROM_SRC/build/release/lib/libasn1.so.8 
(0xf45cd000)
libwind.so.0 => /home/SYSROM_SRC/build/release/lib/libwind.so.0 
(0xf45a3000)
libroken.so.18 => /home/SYSROM_SRC/build/release/lib/libroken.so.18 
(0xf458d000)
libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xf455b000)
libheimntlm.so.0 => /home/SYSROM_SRC/build/release/lib/libheimntlm.so.0 
(0xf4555000)
libintlc.so.5 => /mfp/lib/libintlc.so.5 (0xf44f1000)
libkrb5.so.3 => /usr/lib/i386-linux-gnu/libkrb5.so.3 (0xf441d000)
libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0xf4418000)

Here libcrypto.so.1.1 is newly generated using openssl 1.1.1b and 
libcrypto.so.1.0.0 is one provided by OS.
readelf for same application is below.

Dynamic section at offset 0xc29258 contains 48 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libpam.so.0]
 0x0001 (NEEDED) Shared library: [libldap-2.4.so.2]
 0x0001 (NEEDED) Shared library: [libssl.so.1.1]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libsqlite3.so.0]
 0x0001 (NEEDED) Shared library: [libcrypto.so.1.1]
 0x0001 (NEEDED) Shared library: [libk5crypto.so.3]
 0x0001 (NEEDED) Shared library: [libresolv.so.2]
 0x0001 (NEEDED) Shared library: [libext2fs.so.2]
 0x0001 (NEEDED) Shared library: [libuuid.so.1]
 0x0001 (NEEDED) Shared library: [libdns.so.69]
 0x0001 (NEEDED) Shared library: 

AW: Performance Issue With OpenSSL 1.1.1c

[Dr. Matthias St. Pierre]

> 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