Re: [openssl-users] Cygwin untar of 1.0.1n gives "tar: A lone zero block at 46120"

2015-06-12 Thread avery . a . tarasov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Was the md5 hash of the archive matching the one on openssl website?

On Fri, Jun 12 at 06:49 PM (UTC), "Kevin Layer"  wrote:

> It seems to build fine, though.
>
> I downloaded it via different means (directly to a Windows
> machine and
> on CentOS 6.6) and it did it on all copies.
>
> Just curious if anyone else had the issue.
>
> I'm running Cygwin 1.7.35 on Server 2008 R2.
>
> ___
> openssl-users mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
-BEGIN PGP SIGNATURE-
Charset: UTF8
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 3.0

wsBcBAEBAgAGBQJVezykAAoJEFXbLWdqxjhau0AIAJm7ouwddcTJixc7U+eqnvZgdLcR
etN9VhONFRN0zU6hmdanMUb8WAmHeujUpu+yhvolO9bP21pE7xDtdRRbyrwAwl2vYvzU
68klgLaRE2LeoPy/9iSLnr9Y1i2yXuiVaYC4TtPR4g3vbVryiLjPuVAOJejUKHq9oet1
i9DZyNZvs2X+0Qk65vjLsnN1QS8n22YbsORDV76scJ2XoGjura+Y6gKJ3spJgu8+kU3Z
sQTLbnD4zJEniNvjpAbboLRBOFtrj2QnY6N4NdAY4zllwR44He93X+7w3GAEPcrShlnT
eD6MnNeG0vkblVpQOEw3APGh0iK5yfl9eNaQUD/ijH0=
=XZl9
-END PGP SIGNATURE-

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] cannot configure openssl-1.0.1n on Windows with msys --target already defined - (offending arg: mingw) -- the issue does not occur in openssl-1.0.1l and openssl-1.0.1m.

2015-06-11 Thread Avery A. Tarasov 
The problem goes away if I comment out the "die" statement on line 942 
from the "Configure" file:


else
{
*#die "target already defined - $target (offending arg: 
$_)\n" if ($target ne "");*

$target=$_;
}

Is the above safe and the correct fix?  Does the *$target=$_; *line 
(#943) also need to be commented out?


Best Regards,

-Avery

On 6/11/2015 2:56 PM, Avery A. Tarasov wrote:

Hi All,

I was able to compile openssl 1.0.1l and openssl 1.0.1m perfectly via 
msys in Windows 8 -- but something isn't working right with openssl 1.0.1n


*Exact steps using msys causing the error:*

tar xvzf openssl-1.0.1n.tar.gz
cd openssl-1.0.1n
export PATH=/c/mingw/bin:$PATH
$ ./Configure --prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared 
no-threads mingw


*Error is:*

*target already defined - User Name/Desktop/openssl-1.0.1n/dist 
(offending arg: mingw)*


I am not doing anything differently from what worked previously in 
1.0.1l and 1.0.1m


Please advise if you know how to fix this.  Thanks so much for the help!

Best Regards,

-Avery


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] cannot configure openssl-1.0.1n on Windows with msys --target already defined - (offending arg: mingw) -- the issue does not occur in openssl-1.0.1l and openssl-1.0.1m.

2015-06-11 Thread Avery A. Tarasov 

Hi All,

I was able to compile openssl 1.0.1l and openssl 1.0.1m perfectly via 
msys in Windows 8 -- but something isn't working right with openssl 1.0.1n


*Exact steps using msys causing the error:*

tar xvzf openssl-1.0.1n.tar.gz
cd openssl-1.0.1n
export PATH=/c/mingw/bin:$PATH
$ ./Configure --prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared 
no-threads mingw


*Error is:*

*target already defined - User Name/Desktop/openssl-1.0.1n/dist 
(offending arg: mingw)*


I am not doing anything differently from what worked previously in 
1.0.1l and 1.0.1m


Please advise if you know how to fix this.  Thanks so much for the help!

Best Regards,

-Avery
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l

2015-01-25 Thread Avery A. Tarasov 

Hi Michel,

I actually already tried _beginthread but got the same results. 
CrtDumpMemoryLeaks also reports no problems for me.  I guess the tool I 
was using for leak detection just has some bugs in it.


Thanks again for your help.

Best Regards,

-Avery

On 1/25/2015 1:49 PM, Michel SALES wrote:

Hi Avery,


In the code I sent over before, I was calling CloseHandle on the thread:
HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);  if(h1==0) { return

0; } CloseHandle(h1);

Yes, but you were trying to close the handle of a thread which was still
running !
I have not checked what happens in this case.

I am not sure to fully understand what your are doing now, but with the
modified version I've sent to you, _CrtDumpMemoryLeaks() doesn't report any
problem on my Windows 7 64 bits machine.

Just another quick idea : why not try _beginthread() instead of
CreateThread() ?

Michel




___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l

2015-01-25 Thread Avery A. Tarasov 

Hi Michel,

In the code I sent over before, I was calling CloseHandle on the thread:

HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);  if(h1==0)  {  return 0; }*CloseHandle(h1);*  



 I modified the code you sent slightly so the cleanup functions all get 
reached.  Still getting handle leaks (see info at bottom of the email 
thread).  In the code below, I check the program for leaks once the 
MessageBox pops up after all the cleanup functions.  Then there is a 20 
second pause after which the program exits.


The results are the same as before.. why is it that the program doesn't 
leak anymore if the creation of the thread is removed which essentially 
does nothing?  Also why is it that if all the SSL functions are removed 
in the program, but the thread is still created the leaks go away?  
Something weird is going on. It is as if OpenSSL just doesn't like the 
CreateThread function being used (even if the thread doesn't do anything 
related to OpenSSL (tried modifying code in the thread to do nothing -- 
e.g. blank thread). Thanks for the help, all.


for( int i=0; i<7; i++ ) Sleep(1000);

  CloseHandle( h1 );

ERR_remove_state(0);
EVP_cleanup();
ERR_free_strings();
CRYPTO_cleanup_all_ex_data();
sk_SSL_COMP_free( SSL_COMP_get_compression_methods());

_CrtDumpMemoryLeaks();

*MessageBox*(0,"gothere","gothere",0); *// at this point Handle leaks 
are still being reported... see data below*


Sleep(2);




Address / Handle: 0xC001
shmem-win32.c
sslleak.exe
Atom
0 bytes
Thread ID: 14524
1/25 11:38:34 827ms (Lifetime:00:00:39:561ms)
Sequence: 11
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]
sslleak.exe  _fc_key_init_once : [unwind-sjlj.c Line 0]
sslleak.exe  ___tmainCRTStartup : [crtexe.c Line 0]
kernel32.dll  BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0]
ntdll.dll  RtlInitializeExceptionChain : 
[{FUNC}RtlInitializeExceptionChain Line 0]
ntdll.dll  RtlInitializeExceptionChain : 
[{FUNC}RtlInitializeExceptionChain Line 0]




Address / Handle: 0xC004
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 14524
1/25 11:38:34 827ms (Lifetime:00:00:39:561ms)
Sequence: 27
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  _mutex_ref_init : [mutex.c Line 0]
sslleak.exe  _enterOnceObject : [thread.c Line 0]
sslleak.exe  ___tmainCRTStartup : [crtexe.c Line 0]
kernel32.dll  BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0]
ntdll.dll  RtlInitializeExceptionChain : 
[{FUNC}RtlInitializeExceptionChain Line 0]


Address / Handle: 0xC00F
shmem-win32.c
sslleak.exe
Atom
0 bytes
Thread ID: 14524
1/25 11:38:34 827ms (Lifetime:00:00:39:561ms)
Sequence: 97
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]

Address / Handle: 0xC009
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 14524
1/25 11:38:34 827ms (Lifetime:00:00:39:561ms)
Sequence: 61
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  _mutex_static_init : [mutex.c Line 0]
sslleak.exe  _pop_pthread_mem : [thread.c Line 0]
sslleak.exe  _pop_pthread_mem : [thread.c Line 0]



Address / Handle: 0xC012
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 14524
1/25 11:38:34 842ms (Lifetime:00:00:39:546ms)
Sequence: 112
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  _rwlock_static_init : [rwlock.c Line 0]
sslleak.exe  _rwlock_static_init : [rwlock.c Line 0]








On 1/25/2015 6:05 AM, Michel SALES wrote:

Hi Avery,

I am afraid your program demonstrates very little.

If you load OpenSSL library, you have to call some of the OpenSSL free
functions as indicated in a previous post,
and if you create a thread, you have to call CloseHandle() :

#include 
#include 

#include 
#include 

DWORD __stdcall thread1( LPVOID l )
{
 for( int i=0; i<7; i++ )
 Sleep(1000);
 ERR_remove_state(0);
 return 0;
}

int main( int argc, char* argv[] )
{
//  _crtBreakAlloc = ...;

 SSL_library_init();
 SSL_load_error_strings();

 DWORD  t1;
 HANDLE h1 = CreateThread( 0, 0, thread1, 0, 0, &t1 );

 for( int i=0; i<7; i++ ) Sleep(1000);

 if( h1 ) {
 WaitForSingleObject( thread1, INFINITE );
 CloseHandle( h1 );
 }
 
 ERR_remove_state(0);

 EVP_cleanup();
 ERR_free_strings();
 CRYPTO_cleanup_all_ex_data();
 sk_SSL_COMP_free( SSL_COMP_get_compression_methods());

 _CrtDumpMemoryLeaks();

 return 0;
}

Hope it helps,

Michel


De : openssl-users [mailto:openssl-users-boun...@openssl.org] De la part de
Avery A. Tarasov
Envoyé : samedi 24 janvier 2015 22:34
À : openssl-users@openssl.org
Objet : Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL
1.0.1l

Hi Michel,

It doesn't appear to be related to that.  I added CloseHandle's and got the
same result.

Here are my updated findings... The following simple program still causes
the same Handle L

Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l

2015-01-24 Thread Avery A. Tarasov 

Hi Michel,

It doesn't appear to be related to that.  I added CloseHandle's and got 
the same result.


Here are my updated findings... The following simple program still 
causes the same Handle Leaks...


Important findings:

*1) * IfSSL_library_init() and SSL_load_error_strings() are 
*removed* (which are the only 2 OpenSSL functions I'm using) the 
handle leaks go away..


*2)*  IfSSL_library_init() and SSL_load_error_strings() are *kept* 
but the creation of the thread is *removed* -- no more handle leaks..


So the problem is something related to the combination of loading 
OpenSSL and creating a thread (even though that thread does nothing 
whatsoever related to OpenSSL).  Very odd.



DWORD __stdcall thread1(LPVOID l)
{
while(1)
{   Sleep(1000);}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 
lpCmdLine, int nCmdShow) {



* SSL_library_init();**   // if these 2 lines removed
**SSL_load_error_strings(); **// no more handle leaks*
DWORD t1;

HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);  if(h1==0) {  return 
0; }  CloseHandle(h1); *//if **SSL_library_init();***and 
*SSL_load_error_strings(); *are *kept *but this line is *removed... no 
more handle leaks*



while(1)
{
Sleep(1000);
}
}







Address / Handle: 0xC001
shmem-win32.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:01:45:503ms)
Sequence: 11
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]
sslleak.exe  _fc_key_init_once : [unwind-sjlj.c Line 0]
sslleak.exe  _main : [crt0_c.c Line 0]
sslleak.exe  ___tmainCRTStartup : [crtexe.c Line 0]
kernel32.dll  BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0]
ntdll.dll  RtlInitializeExceptionChain : 
[{FUNC}RtlInitializeExceptionChain Line 0]




Address / Handle: 0xC00F
shmem-win32.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:02:29:683ms)
Sequence: 97
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]


Address / Handle: 0xC016
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:03:02:693ms)
Sequence: 143
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]


Address / Handle: 0xC009
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:03:22:364ms)
Sequence: 61
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  _mutex_static_init : [mutex.c Line 0]
sslleak.exe  _pop_pthread_mem : [thread.c Line 0]
sslleak.exe  _pop_pthread_mem : [thread.c Line 0]



On 1/24/2015 5:34 AM, Michel SALES wrote:


Hi,

Just a quick answer : I didn't find any call to CloseHandle() function 
in your code.


Best regards,

Michel.



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Is CRYPTO_set_locking_callback necessary in multi-threaded OpenSSL program that already uses mutexes to make sure threads can't run at the same time?

2015-01-23 Thread Avery A. Tarasov 

I am using OpenSSL 1.0.1l in Win32 environment.

In the main section of the program I initialize the SSL library and load 
the error strings.


Then I create two threads that run concurrently.  One sends GET requests 
to a website and the other sends POST requests to a website using SSL -- 
both threads do this in an infinite loop with a 100 millisecond pause.  
No variables are shared between the two threads.  Everything is declared 
locally.


I use a mutex to make sure it is impossible for the two threads to be 
running at the time (so basically each thread does its work between a 
WaitForSingleObject and ReleaseMutex call)


In this situation, am I correct that there is no need to use 
CRYPTO_set_locking_callback ?   My  program has been running for 3+ days 
and never had a crash or error.
 Although the documention says this CRYPTO_set_locking_callback 
function is needed for mufti-threaded programs, I don't see why in the 
above situation it would be.


Please advise.

Thanks,

-Avery
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l

2015-01-22 Thread Avery A. Tarasov 
I have a fairly simple Win32 application (.cpp file source code 
attached) that uses OpenSSL 1.0.1l to send some GET requests in 2 
threads.  I am getting reports of Handle Leaks in C++ memory validator 
(see logs at bottom of email), but I can't find what is wrong with my 
code (if anything).  The app appears to function perfectly and the 
memory doesn't appear to rise in task manager.. but I'm still worried 
about the Handle Leak reports.


* It should be noted that even if I get rid of the threads all together 
and just call 2 functions for the GET requests, I still get these same 
leak reports. So I don't think its a thread related problem.


Also, the reason I'm not using CRYPTO_set_locking_callback is because I 
am already using WaitForSingleObject and ReleaseMutex to make sure its 
impossible for two threads to be running at the same time. Unless I'm 
missing something, CRYPTO_set_locking_callback is not needed due to the 
way I coded this.


Can someone please verify if the code is thread safe, and comment 
regarding what might be causing these handle leaks?  Maybe it is nothing 
to be worried about -- not sure..


Are there any other problems you see in the code?  Perhaps missing 
cleanup functions?  Or is everything OK and I'm just over analyzing this?


Thanks for any tips!

Best Regards,

-Avery


Address / Handle: 0xC001
shmem-win32.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:01:45:503ms)
Sequence: 11
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]
sslleak.exe  _fc_key_init_once : [unwind-sjlj.c Line 0]
sslleak.exe  _main : [crt0_c.c Line 0]
sslleak.exe  ___tmainCRTStartup : [crtexe.c Line 0]
kernel32.dll  BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line 0]
ntdll.dll  RtlInitializeExceptionChain : 
[{FUNC}RtlInitializeExceptionChain Line 0]




Address / Handle: 0xC00F
shmem-win32.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:02:29:683ms)
Sequence: 97
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]
sslleak.exe  ___shmem_grab : [shmem-win32.c Line 0]


Address / Handle: 0xC016
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:03:02:693ms)
Sequence: 143
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]


Address / Handle: 0xC009
shmem.c
sslleak.exe
Atom
0 bytes
Thread ID: 6736
1/22 18:48:09 990ms (Lifetime:00:03:22:364ms)
Sequence: 61
sslleak.exe  ___shmem_winpthreads_grab : [shmem.c Line 0]
sslleak.exe  _mutex_static_init : [mutex.c Line 0]
sslleak.exe  _pop_pthread_mem : [thread.c Line 0]
sslleak.exe  _pop_pthread_mem : [thread.c Line 0]





#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
HANDLE sslmutex=0;
int checks(X509_STORE_CTX *c, void *v)
{
return 1;
}
void SSLGO_111()
{
SSL_CTX *myct;
myct = SSL_CTX_new(TLSv1_2_method());
if(myct==NULL)
{
ERR_remove_state(0);
return;
}
SSL_CTX_set_verify(myct,SSL_VERIFY_PEER, NULL);
SSL_CTX_set_cert_verify_callback(myct, checks, "K");
std::string http_resp;
std::string headers="GET /111 HTTP/1.1\r\nHost: removed.com\r\nAccept: 
*/*\r\nUser-Agent: Test\r\n\r\n";
X509 *pcc=0;
SSL *thessl=0;
BIO *bcc = NULL;
char buf[513];
int ret;
bcc = BIO_new_connect("removed.com:443");
if (!bcc) 
{
goto sslend;
}
if (BIO_do_connect(bcc)<=0) 
{
goto sslend;
}
thessl=SSL_new(myct);
if (!thessl )
{
goto sslend;
}
SSL_set_bio(thessl, bcc, bcc);
if (SSL_connect(thessl)<=0)
{
goto sslend;
}
pcc=SSL_get_peer_certificate(thessl);
if(pcc==NULL)
{
goto sslend;
}
ret=SSL_write(thessl, headers.c_str(),headers.length());
if(ret<0)
{
goto sslend;
}
while(1)
{
memset(buf,0x0,sizeof(buf));
int r=SSL_read(thessl,buf,512);
  
switch(SSL_get_error(thessl,r))
{
case SSL_ERROR_SYSCALL:
goto sslend;
case SSL_ERROR_ZERO_RETURN:
goto sslend;
case SSL_ERROR_NONE:
http_resp+=buf;
break;
default:
;
  }
  }


sslend:

if(pcc)
{
X509_free(pcc);
}
if (thessl) 
{
SSL_shutdown(thessl);
SSL_free(thessl);

} 
else 
if (bcc) 
{
BIO_free(bcc);
}

if(myct)
{
SSL_CT

[openssl-users] Proper cleanup functions being called?

2015-01-21 Thread Avery A. Tarasov 

Hi All,

I am using OpenSSL 1.0.1lin Win32 environment.  At the beginning of my 
program I call


SSL_library_init();
SSL_load_error_strings();

Those functions are only called once.

Then I have 3 threads which can't possibly be run at the same time due 
to mutexes I'm setting with WaitForSingleObject and ReleaseMutex.  Those 
3 threads use these functions below and all variables in those threads 
are local to the threads (e.g. no globals).


SSL_CTX_new
SSL_CTX_set_verify
SSL_CTX_set_cert_verify_callback
BIO_new_connect
BIO_do_connect
SSL_new
SSL_set_bio
SSL_get_peer_certificate
SSL_write
SSL_read
SSL_get_error


(cleanup functions.. if conditions used to prevent double frees, etc.)
X509_free
SSL_shutdown
SSL_free
BIO_free
SSL_CTX_free




My questions are the following:

1)  Am I correct that I only need to call the SSL_library_init(); and 
SSL_load_error_strings();  once at the beginning of the program , and 
not at the beginning of each thread?

2)  Should I be doing any other cleanup functions within the threads?

My program appears to work perfectly but a tool is complaining about 
memory leaks in _CRYPTO_malloc, _asn1_enc_save,  _asn1_item_ex_d2i, 
_d2i_X509


Handle leaks

_shmem_winpthreads_grab
_pthread_register_pointer

In fact I get memory leaks reported if I just do SSL_library_init(); alone

Despite the reports of the leaks my program seems to run fine for days 
and stay consistent in memory used.  But I'm feeling paranoid something 
just isn't quite right.


Should I be doing any other cleanup operations?

Thanks for the assistance.

Best Regards,

-Avery T.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Is CRYPTO_set_locking_callback still needed if mutexes in threads are already being used to prevent race conditions?

2015-01-18 Thread Avery A. Tarasov 

Hi, I am developing a Windows C++ application that uses OpenSSL.

The application has 2 threads created by CreateThread that perform SSL 
functions such as connecting to a website over HTTPS and 
sending/receiving data


I am already using a mutex  to prevent race conditions, like this:

static HANDLE sslmutex=0;  // global variable at top of file

*inside thread #1:*
while(1)
{
WaitForSingleObject(sslmutex,INFINITE);
DoSsl();
ReleaseMutex(sslmutex);
Sleep(1000);
}

*inside thread #2:*

while(1)
{
WaitForSingleObject(sslmutex,INFINITE);
DoSsl();
ReleaseMutex(sslmutex);
Sleep(1000);
}

All SSL related code is in the DoSsl function including 
SSL_library_init(), sending/receiving data, and necessary clean up 
operations.


Is it still necessary for me to use CRYPTO_set_locking_callback or is my 
code already thread safe?


Any assistance greatly appreciated.

Best Regards,

-Avery


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users