Re: 'in_addr_t' in openssl 1.1.1g ??

[Benjamin Kaduk via openssl-users]

Ah, so it really is the "gcc" configure target (I had to look up that such
a thing even existed!).

Unfortunately, 'gcc' implies 32-bit, and your x86_64-fslsdk-linux suggests
that you're targetting a 64-bit system.  Such a mismatch of configurations
could easily cause this sort of compile error due to inconsistent input
to the preprocessor conditionals.  Would linux-x86_64 be more appropriate
for your system?

-Ben

On Thu, Aug 06, 2020 at 02:23:40AM +0530, prudvi raj wrote:
> Another thing ,  'make && make all '  is successful , but the same openssl
> files when compiled during my project's compilation show this error .
> PROJECT DIR  << make project here compiles all files.
> |- ..folder 1.
> |- openssl
> |-...
> Btw, Project uses same CC  -
> "/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-gcc"
> Hope this clears some things up.
> $ ./configdata.pm -d
> 
> Command line (with current working directory = .):
> 
> /usr/bin/perl ./Configure no-threads no-dso no-ct no-shared no-zlib
> no-asm no-engine no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4
> no-mdc2 no-ocsp no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc
> --with-rand-seed=none
> --cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-
> 
> Perl information:
> 
> /usr/bin/perl
> 5.10.1 for x86_64-linux-thread-multi
> 
> Enabled features:
> 
> async
> autoalginit
> autoerrinit
> autoload-config
> buildtest-c\+\+
> capieng
> chacha
> cmac
> cms
> comp
> deprecated
> des
> dgram
> dh
> dsa
> dtls
> ec
> ec2m
> ecdh
> ecdsa
> err
> filenames
> gost
> hw(-.+)?
> makedepend
> multiblock
> nextprotoneg
> pinshared
> ocb
> poly1305
> posix-io
> psk
> rc4
> rdrand
> rfc3779
> rmd160
> scrypt
> seed
> siphash
> sm2
> sm3
> sm4
> sock
> srtp
> sse2
> ssl
> static-engine
> stdio
> tests
> 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:
> 
> afalgeng[cascade]  OPENSSL_NO_AFALGENG
> aria[option]   OPENSSL_NO_ARIA (skip
> crypto/aria)
> asan[default]  OPENSSL_NO_ASAN
> asm [option]   OPENSSL_NO_ASM
> bf  [option]   OPENSSL_NO_BF (skip
> crypto/bf)
> blake2  [option]   OPENSSL_NO_BLAKE2 (skip
> crypto/blake2)
> camellia[option]   OPENSSL_NO_CAMELLIA (skip
> crypto/camellia)
> cast[option]   OPENSSL_NO_CAST (skip
> crypto/cast)
> crypto-mdebug   [default]  OPENSSL_NO_CRYPTO_MDEBUG
> crypto-mdebug-backtrace [default]
>  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> ct  [option]   OPENSSL_NO_CT (skip
> crypto/ct)
> devcryptoeng[default]  OPENSSL_NO_DEVCRYPTOENG
> dso [option]   OPENSSL_NO_DSO
> dynamic-engine  [cascade]
> ec_nistp_64_gcc_128 [default]
>  OPENSSL_NO_EC_NISTP_64_GCC_128
> egd [default]  OPENSSL_NO_EGD
> engine  [option]   OPENSSL_NO_ENGINE (skip
> crypto/engine, engines)
> external-tests  [default]  OPENSSL_NO_EXTERNAL_TESTS
> fuzz-libfuzzer  [default]  OPENSSL_NO_FUZZ_LIBFUZZER
> fuzz-afl[default]  OPENSSL_NO_FUZZ_AFL
> heartbeats  [default]  OPENSSL_NO_HEARTBEATS
> idea[option]   OPENSSL_NO_IDEA (skip
> crypto/idea)
> md2 [option]   OPENSSL_NO_MD2 (skip
> crypto/md2)
> md4 [option]   OPENSSL_NO_MD4 (skip
> crypto/md4)
> mdc2[option]   OPENSSL_NO_MDC2 (skip
> crypto/mdc2)
> msan[default]  OPENSSL_NO_MSAN
> ocsp[option]   OPENSSL_NO_OCSP (skip
> crypto/ocsp)
> pic [no-shared-target]
> rc2 [option]   OPENSSL_NO_RC2 (skip
> crypto/rc2)
> rc5 [option]   OPENSSL_NO_RC5 (skip
> crypto/rc5)
> sctp[default]  OPENSSL_NO_SCTP
> shared  [option]
> srp [option]   OPENSSL_NO_SRP (skip
> crypto/srp)
> ssl-trace   [default]  OPENSSL_NO_SSL_TRACE
> threads [option]
> ubsan   [default] 

Re: 'in_addr_t' in openssl 1.1.1g ??

[prudvi raj]

Another thing ,  'make && make all '  is successful , but the same openssl
files when compiled during my project's compilation show this error .
PROJECT DIR  << make project here compiles all files.
|- ..folder 1.
|- openssl
|-...
Btw, Project uses same CC  -
"/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-gcc"
Hope this clears some things up.
$ ./configdata.pm -d

Command line (with current working directory = .):

/usr/bin/perl ./Configure no-threads no-dso no-ct no-shared no-zlib
no-asm no-engine no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4
no-mdc2 no-ocsp no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc
--with-rand-seed=none
--cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-

Perl information:

/usr/bin/perl
5.10.1 for x86_64-linux-thread-multi

Enabled features:

async
autoalginit
autoerrinit
autoload-config
buildtest-c\+\+
capieng
chacha
cmac
cms
comp
deprecated
des
dgram
dh
dsa
dtls
ec
ec2m
ecdh
ecdsa
err
filenames
gost
hw(-.+)?
makedepend
multiblock
nextprotoneg
pinshared
ocb
poly1305
posix-io
psk
rc4
rdrand
rfc3779
rmd160
scrypt
seed
siphash
sm2
sm3
sm4
sock
srtp
sse2
ssl
static-engine
stdio
tests
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:

afalgeng[cascade]  OPENSSL_NO_AFALGENG
aria[option]   OPENSSL_NO_ARIA (skip
crypto/aria)
asan[default]  OPENSSL_NO_ASAN
asm [option]   OPENSSL_NO_ASM
bf  [option]   OPENSSL_NO_BF (skip
crypto/bf)
blake2  [option]   OPENSSL_NO_BLAKE2 (skip
crypto/blake2)
camellia[option]   OPENSSL_NO_CAMELLIA (skip
crypto/camellia)
cast[option]   OPENSSL_NO_CAST (skip
crypto/cast)
crypto-mdebug   [default]  OPENSSL_NO_CRYPTO_MDEBUG
crypto-mdebug-backtrace [default]
 OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
ct  [option]   OPENSSL_NO_CT (skip
crypto/ct)
devcryptoeng[default]  OPENSSL_NO_DEVCRYPTOENG
dso [option]   OPENSSL_NO_DSO
dynamic-engine  [cascade]
ec_nistp_64_gcc_128 [default]
 OPENSSL_NO_EC_NISTP_64_GCC_128
egd [default]  OPENSSL_NO_EGD
engine  [option]   OPENSSL_NO_ENGINE (skip
crypto/engine, engines)
external-tests  [default]  OPENSSL_NO_EXTERNAL_TESTS
fuzz-libfuzzer  [default]  OPENSSL_NO_FUZZ_LIBFUZZER
fuzz-afl[default]  OPENSSL_NO_FUZZ_AFL
heartbeats  [default]  OPENSSL_NO_HEARTBEATS
idea[option]   OPENSSL_NO_IDEA (skip
crypto/idea)
md2 [option]   OPENSSL_NO_MD2 (skip
crypto/md2)
md4 [option]   OPENSSL_NO_MD4 (skip
crypto/md4)
mdc2[option]   OPENSSL_NO_MDC2 (skip
crypto/mdc2)
msan[default]  OPENSSL_NO_MSAN
ocsp[option]   OPENSSL_NO_OCSP (skip
crypto/ocsp)
pic [no-shared-target]
rc2 [option]   OPENSSL_NO_RC2 (skip
crypto/rc2)
rc5 [option]   OPENSSL_NO_RC5 (skip
crypto/rc5)
sctp[default]  OPENSSL_NO_SCTP
shared  [option]
srp [option]   OPENSSL_NO_SRP (skip
crypto/srp)
ssl-trace   [default]  OPENSSL_NO_SSL_TRACE
threads [option]
ubsan   [default]  OPENSSL_NO_UBSAN
unit-test   [default]  OPENSSL_NO_UNIT_TEST
weak-ssl-ciphers[default]  OPENSSL_NO_WEAK_SSL_CIPHERS
zlib[option]
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 => "-O3",
HASHBANGPERL => "/usr/bin/env perl",
RANLIB => "ranlib",
RC => "windres",
aes_asm_src => "aes_core.c aes_cbc.c",
aes_obj => "aes_core.o aes_cbc.o",
apps_aux_src => "",
apps_init_src => "",
apps_obj => "",
bf_asm_src => "bf_enc.c",
bf_obj => "bf_enc.o",

Re: OpenSSL compliance with Linux distributions

[Benjamin Kaduk via openssl-users]

On Wed, Aug 05, 2020 at 10:28:26PM +0200, Patrick Mooc wrote:
> Thank you very much Kyle for your quick and clear answer.
> 
> The reason why I want to upgrade OpenSSL version, is that I encounter a
> problem with 1 frame exchange between client and server.
> 
> This frame is the first packet sent from client to server (Client Hello
> Packet) and the protocol used for this packet is SSLv2.
> I don't understand why, because I force the use of TLSv1 (in ssl.conf file
> as in application software), but only for this first exchange packet, SSLv2
> is used. All other packets are well using TLSv10 as configured.
> 
> I have also searched for forcing the use of TLSv10 ciphers in OpenSSL
> configuration and in application software, but I didn't succeed doing so.
> 
> That's why I had in idea of upgrading OpenSSL version to avoid the use of
> SSLv2 protocol.
> 
> 
> Thus, if you have any idea of how to solve my problem without upgrading
> OpenSSL version or Linux distribution, It would be very nice.

Using an "SSLv2-compatible" ClientHello is rather distinct from actually using
the SSLv2 protocol; I believe that the former is what is happening for you.

IIRC sending any TLS extension with the ClientHello suppresses the use of the
v2-compatible format, so you might be able to do that.  (I don't remember 
offhand
which extensions are implemented in that old of an OpenSSL version, and
whether they're enabled in the default build, though.)

-Ben

Re: OpenSSL compliance with Linux distributions

[Patrick Mooc]

Dear Skip,

Thank you also very much for your quick answer.

Ok, it could then be interesting to test an upgrade of openSSL on my system.
My project is running on a Compact Flash card, so I think that I can 
test the upgrade directly on a device.



Do you have some advices, some steps to follow (in order to limit risks 
as much as possible) ?



Thank you in advance.

Best Regards,


Le 05/08/2020 à 22:19, Skip Carter a écrit :

Patrick,

I am also supporting servers running very old Linux systems and I can
tell you that YES you can upgrade from source. I have built
   openssl-1.1.1 from source on such systems with no problems.

On Wed, 2020-08-05 at 21:49 +0200, Patrick Mooc wrote:

Hello,

I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian
distribution (Lenny).

Is it possible to upgrade OpenSSL version without upgrading Linux
Debian
distribution ?
If yes, up to which version of OpenSSL ?

Are all versions of OpenSSL compliant with all Linux Debian
distribution ?


Thank you in advance for your answer.

Best Regards,

Re: 'in_addr_t' in openssl 1.1.1g ??

[Benjamin Kaduk via openssl-users]

On Thu, Aug 06, 2020 at 01:51:35AM +0530, prudvi raj wrote:
> Hi there,
> 
> I got this error during compilation , in file b_addr.c :
> In function 'BIO_lookup_ex':
> /b_addr.c:748:9: error: unknown type name 'in_addr_t'
> 
> I see that "in_addr_t" is defined in "netinet/in.h" & "arpa/inet.h" in
> toolchain (typedef uint32_t in_addr_t;).
> i have even tried to #include<> these files directly but that doesn't seem
> to fix the error. Btw, these files are included already , but under
> conditional #if 's.
> 
> I am surprised why the error persists , even after directly including the
> respective source file ??
> 
> Here's the config options i used :
> ./Configure  no-threads no-dso no-ct no-shared no-zlib no-asm no-engine
> no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4 no-mdc2 no-ocsp
> no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc  --with-rand-seed=none
>  
> --cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-
> 
> PS : same error without any cross compile prefix , using only gcc.

The `./configdata.pm -d` output might be helpful.

-Ben

Re: OpenSSL compliance with Linux distributions

[Patrick Mooc]

Thank you very much Kyle for your quick and clear answer.

The reason why I want to upgrade OpenSSL version, is that I encounter a 
problem with 1 frame exchange between client and server.


This frame is the first packet sent from client to server (Client Hello 
Packet) and the protocol used for this packet is SSLv2.
I don't understand why, because I force the use of TLSv1 (in ssl.conf 
file as in application software), but only for this first exchange 
packet, SSLv2 is used. All other packets are well using TLSv10 as 
configured.


I have also searched for forcing the use of TLSv10 ciphers in OpenSSL 
configuration and in application software, but I didn't succeed doing so.


That's why I had in idea of upgrading OpenSSL version to avoid the use 
of SSLv2 protocol.



Thus, if you have any idea of how to solve my problem without upgrading 
OpenSSL version or Linux distribution, It would be very nice.



Thank you in advance for your answer.

Best Regards,


Le 05/08/2020 à 22:10, Kyle Hamilton a écrit :
It is never recommended to upgrade you distribution's version of 
OpenSSL with one you compile yourself.  Doing so will often break all 
software installed by the distribution that uses it.


If you need functionality from newer versions of OpenSSL, your options 
are to upgrade your OS version, or to install a local copy of OpenSSL 
and manually compile and link local copies of the applications that 
need the newer functionality.


(Newer versions of OpenSSL do not maintain the same Application Binary 
Interface (ABI), which means that binaries compiled against older 
versions will not correctly operate or dynamically link against newer 
libraries. Also, distributions such as Debian can modify the ABI in 
such a way that nothing distributed directly by openssl.org 
 can be compiled to meet it without source code 
modification.)


-Kyle H

On Wed, Aug 5, 2020, 14:49 Patrick Mooc > wrote:


Hello,

I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian
distribution (Lenny).

Is it possible to upgrade OpenSSL version without upgrading Linux
Debian
distribution ?
If yes, up to which version of OpenSSL ?

Are all versions of OpenSSL compliant with all Linux Debian
distribution ?


Thank you in advance for your answer.

Best Regards,

'in_addr_t' in openssl 1.1.1g ??

[prudvi raj]

Hi there,

I got this error during compilation , in file b_addr.c :
In function 'BIO_lookup_ex':
/b_addr.c:748:9: error: unknown type name 'in_addr_t'

I see that "in_addr_t" is defined in "netinet/in.h" & "arpa/inet.h" in
toolchain (typedef uint32_t in_addr_t;).
i have even tried to #include<> these files directly but that doesn't seem
to fix the error. Btw, these files are included already , but under
conditional #if 's.

I am surprised why the error persists , even after directly including the
respective source file ??

Here's the config options i used :
./Configure  no-threads no-dso no-ct no-shared no-zlib no-asm no-engine
no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4 no-mdc2 no-ocsp
no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc  --with-rand-seed=none
 
--cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-

PS : same error without any cross compile prefix , using only gcc.

Thanks,
Prudvi.

Re: OpenSSL compliance with Linux distributions

[Skip Carter]

Patrick,

I am also supporting servers running very old Linux systems and I can
tell you that YES you can upgrade from source. I have built
  openssl-1.1.1 from source on such systems with no problems.

On Wed, 2020-08-05 at 21:49 +0200, Patrick Mooc wrote:
> Hello,
> 
> I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian 
> distribution (Lenny).
> 
> Is it possible to upgrade OpenSSL version without upgrading Linux
> Debian 
> distribution ?
> If yes, up to which version of OpenSSL ?
> 
> Are all versions of OpenSSL compliant with all Linux Debian
> distribution ?
> 
> 
> Thank you in advance for your answer.
> 
> Best Regards,
> 
-- 
Dr Everett (Skip) Carter  0xF29BF36844FB7922
s...@taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc
Description: This is a digitally signed message part

Re: OpenSSL compliance with Linux distributions

[Kyle Hamilton]

It is never recommended to upgrade you distribution's version of OpenSSL
with one you compile yourself.  Doing so will often break all software
installed by the distribution that uses it.

If you need functionality from newer versions of OpenSSL, your options are
to upgrade your OS version, or to install a local copy of OpenSSL and
manually compile and link local copies of the applications that need the
newer functionality.

(Newer versions of OpenSSL do not maintain the same Application Binary
Interface (ABI), which means that binaries compiled against older versions
will not correctly operate or dynamically link against newer libraries.
Also, distributions such as Debian can modify the ABI in such a way that
nothing distributed directly by openssl.org can be compiled to meet it
without source code modification.)

-Kyle H

On Wed, Aug 5, 2020, 14:49 Patrick Mooc  wrote:

> Hello,
>
> I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian
> distribution (Lenny).
>
> Is it possible to upgrade OpenSSL version without upgrading Linux Debian
> distribution ?
> If yes, up to which version of OpenSSL ?
>
> Are all versions of OpenSSL compliant with all Linux Debian distribution ?
>
>
> Thank you in advance for your answer.
>
> Best Regards,
>
>

OpenSSL compliance with Linux distributions

[Patrick Mooc]

Hello,

I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian 
distribution (Lenny).


Is it possible to upgrade OpenSSL version without upgrading Linux Debian 
distribution ?

If yes, up to which version of OpenSSL ?

Are all versions of OpenSSL compliant with all Linux Debian distribution ?


Thank you in advance for your answer.

Best Regards,

openssl-3

[mejaz]

 

Hello, 

 

 

I have sucesfully installed openssl 3.x version but when I was trying to
check the version wheather it installed sucesfully or not, it gives error as
below , any assistance would be highly appreciated thanks in advance. 

 

[root@nc ~]# /usr/local/bin/openssl versioin -a

/usr/local/bin/openssl: error while loading shared libraries: libssl.so.3:
cannot open shared object file: No such file or directory

 

 

I have redhat 8 O/S 

 

 

Regards 

Ejaz