date:20200416

Updated openssl 1.1.1f installation problem: Parse errors: No plan found in TAP output

2020-04-16 Thread Justin Chen

Is there anyone meets the same Failure like me?  Pls help me.


The installation steps list below.


[birdnofoots@trojan openssl-1.1.1f]$ cat /proc/version
Linux version 4.14.129-bbrplus (root@vultr.guest ) 
(gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)) #1 SMP Tue Jun 25 
12:23:41 UTC 2019


[birdnofoots@trojan openssl-1.1.1f]$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

[birdnofoots@trojan openssl-1.1.1f]$ perl --version

This is perl 5, version 16, subversion 3 (v5.16.3) built for 
x86_64-linux-thread-multi
(with 39 registered patches, see perl -V for more detail)

Copyright 1987-2012, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/ , 
the Perl Home Page.

[birdnofoots@trojan openssl-1.1.1f]$ ls

ACKNOWLEDGEMENTS  AUTHORS config Configurations  crypto  engines   
FAQ  INSTALL   ms NOTES.DJGPP  NOTES.VMS  README ssl
util
apps  build.info   config.com 
 Configure   demos   e_os.hfuzz LICENSE   
NEWS   NOTES.PERL   NOTES.WIN  README.ENGINE  test   VMS
appveyor.yml  CHANGES configdata.pm   
CONTRIBUTINGdoc external  include  Makefile  NOTES.ANDROID  NOTES.UNIX  
 os-dep README.FIPStools

[birdnofoots@trojan openssl-1.1.1f]$ sudo ./config
Operating system: x86_64-whatever-linux2
Configuring OpenSSL version 1.1.1f (0x1010106fL) for linux-x86_64
Using os-specific seed configuration
Creating configdata.pm 
Creating Makefile

**
******
***   OpenSSL has been successfully configured ***
******
***   If you encounter a problem while building, please open an***
***   issue on GitHub >  ***
***   and include the output from the following command:   ***
******
***   perl configdata.pm  --dump 
   ***
******
***   (If you are new to OpenSSL, you might want to consult the***
***   'Troubleshooting' section in the INSTALL file first) ***
******
**
[birdnofoots@trojan openssl-1.1.1f]$ sudo make test
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \
"-oMakefile" include/crypto/bn_conf.h.in  > 
include/crypto/bn_conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \
"-oMakefile" include/crypto/dso_conf.h.in  > 
include/crypto/dso_conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \
"-oMakefile" include/openssl/opensslconf.h.in  > 
include/openssl/opensslconf.h
make depend && make _tests
make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f'
make[1]: Leaving directory `/home/birdnofoots/openssl-1.1.1f'
make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f'
/usr/bin/perl apps/progs.pl  apps/openssl > apps/progs.h
….
….
./test/recipes/90-test_sysdefault.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_threads.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_time_offset.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_tls13ccs.t   (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_tls13encryption.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_tls13secrets.t   (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_v3name.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/95-test_external_boringssl.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status:

Updated openssl 1.1.1f installation problem: Parse errors: No plan found in TAP output

2020-04-16 Thread Justin Chen

Is there anyone meets the same Failure like me?  Pls help me.


The installation steps list below.


[birdnofoots@trojan openssl-1.1.1f]$ cat /proc/version
Linux version 4.14.129-bbrplus (root@vultr.guest ) 
(gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)) #1 SMP Tue Jun 25 
12:23:41 UTC 2019


[birdnofoots@trojan openssl-1.1.1f]$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

[birdnofoots@trojan openssl-1.1.1f]$ perl --version

This is perl 5, version 16, subversion 3 (v5.16.3) built for 
x86_64-linux-thread-multi
(with 39 registered patches, see perl -V for more detail)

Copyright 1987-2012, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/ , 
the Perl Home Page.

[birdnofoots@trojan openssl-1.1.1f]$ ls

ACKNOWLEDGEMENTS  AUTHORS config Configurations  crypto  engines   
FAQ  INSTALL   ms NOTES.DJGPP  NOTES.VMS  README ssl
util
apps  build.info   config.com 
 Configure   demos   e_os.hfuzz LICENSE   
NEWS   NOTES.PERL   NOTES.WIN  README.ENGINE  test   VMS
appveyor.yml  CHANGES configdata.pm   
CONTRIBUTINGdoc external  include  Makefile  NOTES.ANDROID  NOTES.UNIX  
 os-dep README.FIPStools

[birdnofoots@trojan openssl-1.1.1f]$ sudo ./config
Operating system: x86_64-whatever-linux2
Configuring OpenSSL version 1.1.1f (0x1010106fL) for linux-x86_64
Using os-specific seed configuration
Creating configdata.pm 
Creating Makefile

**
******
***   OpenSSL has been successfully configured ***
******
***   If you encounter a problem while building, please open an***
***   issue on GitHub >  ***
***   and include the output from the following command:   ***
******
***   perl configdata.pm  --dump 
   ***
******
***   (If you are new to OpenSSL, you might want to consult the***
***   'Troubleshooting' section in the INSTALL file first) ***
******
**
[birdnofoots@trojan openssl-1.1.1f]$ sudo make test
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \
"-oMakefile" include/crypto/bn_conf.h.in  > 
include/crypto/bn_conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \
"-oMakefile" include/crypto/dso_conf.h.in  > 
include/crypto/dso_conf.h
/usr/bin/perl "-I." -Mconfigdata "util/dofile.pl " \
"-oMakefile" include/openssl/opensslconf.h.in  > 
include/openssl/opensslconf.h
make depend && make _tests
make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f'
make[1]: Leaving directory `/home/birdnofoots/openssl-1.1.1f'
make[1]: Entering directory `/home/birdnofoots/openssl-1.1.1f'
/usr/bin/perl apps/progs.pl  apps/openssl > apps/progs.h
….
….
./test/recipes/90-test_sysdefault.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_threads.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_time_offset.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_tls13ccs.t   (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_tls13encryption.t(Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_tls13secrets.t   (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/90-test_v3name.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
../test/recipes/95-test_external_boringssl.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status:

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Harald Koch




> Am 16.04.2020 um 22:17 schrieb Benjamin Kaduk :
> 
> On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote:
>> Am 16.04.2020 um 17:54 schrieb Tomas Mraz :
>>> 
>>> error queue of openSSL stays empty. The same code works with
 openSSL with gzip support („./config enable-zlib ...“, for support of
 compressed SMIME contents in other application).
 Do you call the OPENSSL_init_ssl from the main thread or from the
> TLS
> server thread?
 I call it from the TLS server thread (created by pthread_create):
 
 if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
return;
 I tried to do it only once (instead of every started thread): no
 difference.
>>> I do not see how this error could really happen unless
>>> OPENSSL_cleanup() is called.
>>> 
>>> Could you try to set a breakpoint on that function and see if it is
>>> somehow called inadvertently?
>> gdb is actually unavailable, so I added a big „printf“ at the beginning of 
>> crypto/init.c, recompiled (even without zlib support as I’ve seen there’s 
>> much functionality in there), function OPENSSL_cleanup: it’s not called. I’m 
>> very sure OPENSSL_cleanup is not called. 
>> 
>>> In addition, I load random data via /dev/urandom (also tested only
 once or every time the server thread starts):
RAND_load_file("/dev/urandom", 256);
>>> That call should not be necessary.
>> I removed it just in case it may have an influence. No better result. :(
>> 
>> 
>> I have a workaround and possibly it’s the solution, I would like to have 
>> your valuable statement here: you asked where I call OPENSSL_init_ssl: it’s 
>> done in the thread for TLS server. When I initialize it earlier in the main 
>> thread, the subsequent generated (second) thread works as expected! Is this 
>> spooky or expected behaviour?
> 
> Just to check: what OS is this on?
Linux x86-64. Every Debian from 7 to 10 tested.

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Benjamin Kaduk via openssl-users

On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote:
> Am 16.04.2020 um 17:54 schrieb Tomas Mraz :
> > 
> > error queue of openSSL stays empty. The same code works with
> >> openSSL with gzip support („./config enable-zlib ...“, for support of
> >> compressed SMIME contents in other application).
> >> Do you call the OPENSSL_init_ssl from the main thread or from the
> >>> TLS
> >>> server thread?
> >> I call it from the TLS server thread (created by pthread_create):
> >> 
> >> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
> >>return;
> >> I tried to do it only once (instead of every started thread): no
> >> difference.
> > I do not see how this error could really happen unless
> > OPENSSL_cleanup() is called.
> > 
> > Could you try to set a breakpoint on that function and see if it is
> > somehow called inadvertently?
> gdb is actually unavailable, so I added a big „printf“ at the beginning of 
> crypto/init.c, recompiled (even without zlib support as I’ve seen there’s 
> much functionality in there), function OPENSSL_cleanup: it’s not called. I’m 
> very sure OPENSSL_cleanup is not called. 
> 
> > In addition, I load random data via /dev/urandom (also tested only
> >> once or every time the server thread starts):
> >>RAND_load_file("/dev/urandom", 256);
> > That call should not be necessary.
> I removed it just in case it may have an influence. No better result. :(
> 
> 
> I have a workaround and possibly it’s the solution, I would like to have your 
> valuable statement here: you asked where I call OPENSSL_init_ssl: it’s done 
> in the thread for TLS server. When I initialize it earlier in the main 
> thread, the subsequent generated (second) thread works as expected! Is this 
> spooky or expected behaviour?

Just to check: what OS is this on?

-Ben

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Harald Koch

Am 16.04.2020 um 17:54 schrieb Tomas Mraz :
> 
> error queue of openSSL stays empty. The same code works with
>> openSSL with gzip support („./config enable-zlib ...“, for support of
>> compressed SMIME contents in other application).
>> Do you call the OPENSSL_init_ssl from the main thread or from the
>>> TLS
>>> server thread?
>> I call it from the TLS server thread (created by pthread_create):
>> 
>> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
>>  return;
>> I tried to do it only once (instead of every started thread): no
>> difference.
> I do not see how this error could really happen unless
> OPENSSL_cleanup() is called.
> 
> Could you try to set a breakpoint on that function and see if it is
> somehow called inadvertently?
gdb is actually unavailable, so I added a big „printf“ at the beginning of 
crypto/init.c, recompiled (even without zlib support as I’ve seen there’s much 
functionality in there), function OPENSSL_cleanup: it’s not called. I’m very 
sure OPENSSL_cleanup is not called. 

> In addition, I load random data via /dev/urandom (also tested only
>> once or every time the server thread starts):
>>  RAND_load_file("/dev/urandom", 256);
> That call should not be necessary.
I removed it just in case it may have an influence. No better result. :(


I have a workaround and possibly it’s the solution, I would like to have your 
valuable statement here: you asked where I call OPENSSL_init_ssl: it’s done in 
the thread for TLS server. When I initialize it earlier in the main thread, the 
subsequent generated (second) thread works as expected! Is this spooky or 
expected behaviour?

RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10

2020-04-16 Thread Michael Wojcik

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> tim.j.culh...@gmail.com
> Sent: Thursday, April 16, 2020 08:36
>
> I'm building a PIC enabled shared library in my server which links against
> openssl 1.0.2k libssl.a library on Sparc 10.
>
> When compiling  I see the below errors.
>
> I  originally built  the 1.0.2k version of openssl with the following
> configure  arguments:
>
> ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k
> --openssldir=/opt/openssl/1.0.2k -lrt -m64
>
> Do I need to  pass in  the  -fPIC flag as well, and if so  how do I do that.

I believe you do, though our use case is different - we build OpenSSL as a PIC 
archive library, which we then linked into a shared object. If you're building 
OpenSSL as a shared object (well, a pair of shared objects, for libcrypto and 
libssl), then you may be able to do that with the appropriate Configure options.

My teams have switched to 1.1.1, so I don't have a 1.0.2 build handy to check.

> I appended it to the end of the  configure  line I  show above  but there
> was no sign of PIC in any of the top level makefiles produced.

For 1.0.2, we edited the Configure file. We kept a log of the purposes of our 
changes, and looked at the Configure diffs for each new 1.0.2 release so we 
could port the relevant changes back to our Configure.

We haven't had to do that with 1.1.1; its Configure is more flexible.

--

Michael Wojcik
Distinguished Engineer, Micro Focus

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Tomas Mraz

On Thu, 2020-04-16 at 17:32 +0200, Harald Koch wrote:
> > Am 16.04.2020 um 17:07 schrieb Tomas Mraz :
> > 
> > On Thu, 2020-04-16 at 15:42 +0200, Harald Koch wrote:
> > > Hello list,
> > > 
> > > I have a TLS server which is started on demand in a multithreaded
> > > (pthread) application. The TLS server is one thread which is
> > > being
> > > started and stopped. At first start, the TLS server initialized
> > > with
> > > SSL_CTX_new with TLS_server_method works as expected, after
> > > cleaning
> > > up, eliminating the thread and starting it again at a later time
> > > in
> > > the same process, SSL_CTX_new returns NULL. I’ve been digging
> > > deeper
> > > into the initialization code, and found out that in
> > > crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the
> > > call
> > > to pthread_setspecific returns a value != 0 (in my case: 22). The

This is EINVAL - meaning most probably that the pthread_setspecific()
is called on uninitialized key.

> > > error queue of openSSL stays empty. The same code works with
> > > openSSL
> > > 1.1.0 in all versions.
> > > Some posts googled state that before usage, be sure to run
> > > OPENSSL_init_ssl (which I do, even if not required to my analysis
> > > since it’s already called in one of the called functions deeper
> > > in
> > > the library).
> > > Am I missing something in a multithreaded environment?
> > 
> > Is this pure old 1.1.1 version or a current release from the 1.1.1
> > branch (i.e. 1.1.1f)?
> It’s 1.1.1f, also tested 1.1.1c. In 1.1.0t it works. I can test
> against other versions if you want to. As a speciality, I compile
> openSSL with gzip support („./config enable-zlib ...“, for support of
> compressed SMIME contents in other application).
> 
> > Do you call the OPENSSL_init_ssl from the main thread or from the
> > TLS
> > server thread?
> 
> I call it from the TLS server thread (created by pthread_create):
> 
> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
>   return;
> I tried to do it only once (instead of every started thread): no
> difference.

I do not see how this error could really happen unless
OPENSSL_cleanup() is called.

Could you try to set a breakpoint on that function and see if it is
somehow called inadvertently?

> In addition, I load random data via /dev/urandom (also tested only
> once or every time the server thread starts):
>   RAND_load_file("/dev/urandom", 256);

That call should not be necessary.

-- 
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: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Harald Koch




> Am 16.04.2020 um 17:07 schrieb Tomas Mraz :
> 
> On Thu, 2020-04-16 at 15:42 +0200, Harald Koch wrote:
>> Hello list,
>> 
>> I have a TLS server which is started on demand in a multithreaded
>> (pthread) application. The TLS server is one thread which is being
>> started and stopped. At first start, the TLS server initialized with
>> SSL_CTX_new with TLS_server_method works as expected, after cleaning
>> up, eliminating the thread and starting it again at a later time in
>> the same process, SSL_CTX_new returns NULL. I’ve been digging deeper
>> into the initialization code, and found out that in
>> crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the call
>> to pthread_setspecific returns a value != 0 (in my case: 22). The
>> error queue of openSSL stays empty. The same code works with openSSL
>> 1.1.0 in all versions.
>> Some posts googled state that before usage, be sure to run
>> OPENSSL_init_ssl (which I do, even if not required to my analysis
>> since it’s already called in one of the called functions deeper in
>> the library).
>> Am I missing something in a multithreaded environment?
> 
> Is this pure old 1.1.1 version or a current release from the 1.1.1
> branch (i.e. 1.1.1f)?
It’s 1.1.1f, also tested 1.1.1c. In 1.1.0t it works. I can test against other 
versions if you want to. As a speciality, I compile openSSL with gzip support 
(„./config enable-zlib ...“, for support of compressed SMIME contents in other 
application).

> Do you call the OPENSSL_init_ssl from the main thread or from the TLS
> server thread?

I call it from the TLS server thread (created by pthread_create):

if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
return;
I tried to do it only once (instead of every started thread): no difference.

In addition, I load random data via /dev/urandom (also tested only once or 
every time the server thread starts):
RAND_load_file("/dev/urandom", 256);

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Tomas Mraz

On Thu, 2020-04-16 at 15:42 +0200, Harald Koch wrote:
> Hello list,
> 
> I have a TLS server which is started on demand in a multithreaded
> (pthread) application. The TLS server is one thread which is being
> started and stopped. At first start, the TLS server initialized with
> SSL_CTX_new with TLS_server_method works as expected, after cleaning
> up, eliminating the thread and starting it again at a later time in
> the same process, SSL_CTX_new returns NULL. I’ve been digging deeper
> into the initialization code, and found out that in
> crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the call
> to pthread_setspecific returns a value != 0 (in my case: 22). The
> error queue of openSSL stays empty. The same code works with openSSL
> 1.1.0 in all versions.
> Some posts googled state that before usage, be sure to run
> OPENSSL_init_ssl (which I do, even if not required to my analysis
> since it’s already called in one of the called functions deeper in
> the library).
> Am I missing something in a multithreaded environment?

Is this pure old 1.1.1 version or a current release from the 1.1.1
branch (i.e. 1.1.1f)?

Do you call the OPENSSL_init_ssl from the main thread or from the TLS
server thread?

-- 
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: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Harald Koch

Hi Matt,

> Am 16.04.2020 um 16:29 schrieb Matt Caswell :
> On 16/04/2020 14:42, Harald Koch wrote:
>> Hello list,
>> 
>> I have a TLS server which is started on demand in a multithreaded (pthread) 
>> application. The TLS server is one thread which is being started and 
>> stopped. At first start, the TLS server initialized with SSL_CTX_new with 
>> TLS_server_method works as expected, after cleaning up, eliminating the 
>> thread and starting it again at a later time in the same process, 
>> SSL_CTX_new returns NULL. I’ve been digging deeper into the initialization 
>> code, and found out that in crypto/threads_pthread.c, function
> What does your clean up code look like? Are you taking specific steps to
> cleanup OpenSSL and if so what are they?

I’m checking if my actually used SSL and CTX are up, and if so, cleanup them 
before thread killing:

if(ssl != NULL) { // assigned by SSL_new before
SSL_free(ssl);
ssl = NULL;
}
/* Free the SSL_CTX structure */
if(ctx != NULL) { // assigned by SSL_CTX_new before
SSL_CTX_free(ctx);
ctx = NULL;
}

No other openSSL specific cleanup functions are called. The functions 
documented in https://wiki.openssl.org/index.php/Library_Initialization#Cleanup 
 are not 
called.


> CRYPTO_THREAD_set_local the call to pthread_setspecific returns a value
> != 0 (in my case: 22). The error queue of openSSL stays empty. The same
> code works with openSSL 1.1.0 in all versions.
>> Some posts googled state that before usage, be sure to run OPENSSL_init_ssl 
>> (which I do, even if not required to my analysis since it’s already called 
>> in one of the called functions deeper in the library).
>> Am I missing something in a multithreaded environment?

building a PIC enabled version of openssl 1.0.2k on Sparc 10

2020-04-16 Thread tim.j.culhane

Hi,

I'm building a PIC enabled shared library in my server which links against
openssl 1.0.2k libssl.a library on Sparc 10.

When compiling  I see the below errors.

I  originally built  the 1.0.2k version of openssl with the following
configure  arguments:

./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k
--openssldir=/opt/openssl/1.0.2k -lrt -m64

Do I need to  pass in  the  -fPIC flag as well, and if so  how do I do that.

I appended it to the end of the  configure  line I  show above  but there
was no sign of PIC in any of the top level makefiles produced.


Thanks,

Tim

gcc -shared -static-libgcc -m64 -o libsncrssl1.0-openssl1.0.x.so
.objects/sha1_pic.o .objects/sha256_pic.o .objects/tls_openssl_pic.o
.objects/olog_signature_pic.o .objects/utils_pic.o .objects/rsa_sha_pic.o
.objects/rsa_sha1_pic.o .objects/rsa_sha256_pic.o
.objects/ed25519_sha256_pic.o -L/opt/openssl/1.0.2k/lib -lssl -lcrypto
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations b

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Matt Caswell




On 16/04/2020 14:42, Harald Koch wrote:
> Hello list,
> 
> I have a TLS server which is started on demand in a multithreaded (pthread) 
> application. The TLS server is one thread which is being started and stopped. 
> At first start, the TLS server initialized with SSL_CTX_new with 
> TLS_server_method works as expected, after cleaning up, eliminating the 
> thread and starting it again at a later time in the same process, SSL_CTX_new 
> returns NULL. I’ve been digging deeper into the initialization code, and 
> found out that in crypto/threads_pthread.c, function

What does your clean up code look like? Are you taking specific steps to
cleanup OpenSSL and if so what are they?

Matt



 CRYPTO_THREAD_set_local the call to pthread_setspecific returns a value
!= 0 (in my case: 22). The error queue of openSSL stays empty. The same
code works with openSSL 1.1.0 in all versions.
> Some posts googled state that before usage, be sure to run OPENSSL_init_ssl 
> (which I do, even if not required to my analysis since it’s already called in 
> one of the called functions deeper in the library).
> Am I missing something in a multithreaded environment?
> 
> Regards,
> Harald
>

Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

2020-04-16 Thread Harald Koch

Hello list,

I have a TLS server which is started on demand in a multithreaded (pthread) 
application. The TLS server is one thread which is being started and stopped. 
At first start, the TLS server initialized with SSL_CTX_new with 
TLS_server_method works as expected, after cleaning up, eliminating the thread 
and starting it again at a later time in the same process, SSL_CTX_new returns 
NULL. I’ve been digging deeper into the initialization code, and found out that 
in crypto/threads_pthread.c, function CRYPTO_THREAD_set_local the call to 
pthread_setspecific returns a value != 0 (in my case: 22). The error queue of 
openSSL stays empty. The same code works with openSSL 1.1.0 in all versions.
Some posts googled state that before usage, be sure to run OPENSSL_init_ssl 
(which I do, even if not required to my analysis since it’s already called in 
one of the called functions deeper in the library).
Am I missing something in a multithreaded environment?

Regards,
Harald

Re: Add user-defined argument in TLS 1.3 External PSK callback

2020-04-16 Thread Matt Caswell




On 16/04/2020 00:12, brandon.murphy1996 via openssl-users wrote:
> Currently, the psk_use_session_cb_func() contains a hardcoded PSK and
> identity value. However, I want to send an extra argument (preferably
> a custom struct) to this callback that will contain the pre-shared
> key and identity (ideally read from a config file). Is there any way
> this can be achieved?

You could store "ex_data" on the SSL object using SSL_set_ex_data():

https://www.openssl.org/docs/man1.1.1/man3/SSL_set_ex_data.html


Matt

Updated openssl 1.1.1f installation problem: Parse errors: No plan found in TAP output

Updated openssl 1.1.1f installation problem: Parse errors: No plan found in TAP output

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

building a PIC enabled version of openssl 1.0.2k on Sparc 10

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

Re: Add user-defined argument in TLS 1.3 External PSK callback

14 matches

Site Navigation

Mail list logo

Footer information