Re: Cygwin compilation fails with 0.9.7-stable

2002-12-15 Thread Doug Kaufman
On Sun, 15 Dec 2002, Richard Levitte - VMS Whacker wrote:

 In message [EMAIL PROTECTED] on Sat, 14 Dec 
2002 23:41:00 -0800 (PST), Doug Kaufman [EMAIL PROTECTED] said:
 
 dkaufman ../libcrypto.a(dx86-out.o)(.text+0x68):des-586.s: undefined reference to 
`DES_SPtrans'
 dkaufman ../libcrypto.a(dx86-out.o)(.text+0xf3a):des-586.s: undefined reference to 
`DES_SPtrans'
 dkaufman ../libcrypto.a(yx86-out.o)(.text+0x9):crypt586.s: undefined reference to 
`DES_SPtrans'
 dkaufman collect2: ld returned 1 exit status
 dkaufman make[1]: *** [openssl] Error 1
 dkaufman make[1]: Leaving directory 
`/d/CYGWIN/ssl097-1213/openssl-0.9.7-stable-SNAP-20021213/apps'
 dkaufman make: *** [sub_all] Error 1
 
 Hmm, if you do something like 'nm libcrypto.a', can you see the symbol
 DES_SPtrans anywhere?  It should be part of ecb_enc.obj...

It has _DES_SPtrans, but not DES_SPtrans. Results of nm follow:

ecb_enc.o:
 b .bss
 d .data
 t .text
 T _DES_SPtrans
08f0 T _DES_ecb_encrypt
 U _DES_encrypt1
08a0 T _DES_options
0004 D _OSSL_DES_version
 D _OSSL_libdes_version
 t ___gnu_compiled_c
 b _buf.7
0008 d _init.6
 U _sprintf
 t gcc2_compiled.

dx86-out.o:
 b .bss
 d .data
 r .rdata$zzz
 t .text
 U DES_SPtrans
1ec8 T _DES_decrypt3
2198 T _DES_ede3_cbc_encrypt
 T _DES_encrypt1
0f20 T _DES_encrypt2
1da4 T _DES_encrypt3
1fec T _DES_ncbc_encrypt
 t gcc2_compiled.

yx86-out.o:
 b .bss
 d .data
0abe t .fcrypt_body_end
 r .rdata$zzz
 t .text
 U DES_SPtrans
 T _fcrypt_body
 t gcc2_compiled.

Doug
-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Cygwin compilation fails with 0.9.7-stable

2002-12-15 Thread Andy Polyakov
Richard Levitte - VMS Whacker wrote:
 
 In message [EMAIL PROTECTED] on Sat, 14 Dec 
2002 23:41:00 -0800 (PST), Doug Kaufman [EMAIL PROTECTED] said:
 
 dkaufman   gcc -o openssl -DMONOLITH -I.. -I../include  -DOPENSSL_SYSNAME_CYGWIN32 
-DOPENSSL_THREADS  -DDSO_WIN32 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 
-DOPENSSL_NO_MDC2 -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall 
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM openssl.o verify.o asn1pars.o req.o dgst.o dh.o 
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o 
dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o 
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o 
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o  ../libssl.a  ../libcrypto.a  ; \
 dkaufman else \
 dkaufman   gcc -o openssl -DMONOLITH -I.. -I../include  -DOPENSSL_SYSNAME_CYGWIN32 
-DOPENSSL_THREADS  -DDSO_WIN32 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 
-DOPENSSL_NO_MDC2 -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall 
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM openssl.o verify.o asn1pars.o req.o dgst.o dh.o 
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o 
dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o 
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o 
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o  -L.. -lssl  -L.. -lcrypto  ; \
 dkaufman fi
 dkaufman ../libcrypto.a(dx86-out.o)(.text+0x68):des-586.s: undefined reference to 
`DES_SPtrans'
 dkaufman ../libcrypto.a(dx86-out.o)(.text+0xf3a):des-586.s: undefined reference to 
`DES_SPtrans'
 dkaufman ../libcrypto.a(yx86-out.o)(.text+0x9):crypt586.s: undefined reference to 
`DES_SPtrans'
 dkaufman collect2: ld returned 1 exit status
 dkaufman make[1]: *** [openssl] Error 1
 dkaufman make[1]: Leaving directory 
`/d/CYGWIN/ssl097-1213/openssl-0.9.7-stable-SNAP-20021213/apps'
 dkaufman make: *** [sub_all] Error 1
 
 Hmm, if you do something like 'nm libcrypto.a', can you see the symbol
 DES_SPtrans anywhere?  It should be part of ecb_enc.obj...

The torture never stops. It surely have everything to do with DES
PIC-ification. I'll look into it during the day and I'm pretty sure the
fix will be in tonight snapshot. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Make depend fails for gcc (0.9.6h)

2002-12-15 Thread Doug Kaufman
I just compiled openssl-0.9.6h (from CVS) with Cygwin. I configured
with no-idea no-rc5 no-mdc2 no-shared. Make depend fails because
Cygwin has no program named makedepend, which is called by
util/domd. I borrowed the domd from 0.9.7, which has a provision for
gcc being the makedepend program, and the rest of the compilation went
fine, including make test and make install. I am not sure I see
a simple fix, since in 0.9.7 the Configure script determines if the
makedepend program should be gcc or not. Do we need to put this in the
Configure script and modify Makefile.org and util/domd accordingly?

I presume that this applies to any gcc compilation where there is no
separate makedepend program.
   Doug

-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Cygwin compilation fails with 0.9.7-stable

2002-12-15 Thread Andy Polyakov
  dkaufman ../libcrypto.a(dx86-out.o)(.text+0x68):des-586.s: undefined reference to 
`DES_SPtrans'
  dkaufman ../libcrypto.a(dx86-out.o)(.text+0xf3a):des-586.s: undefined reference 
to `DES_SPtrans'
  dkaufman ../libcrypto.a(yx86-out.o)(.text+0x9):crypt586.s: undefined reference to 
`DES_SPtrans'
  dkaufman collect2: ld returned 1 exit status
  dkaufman make[1]: *** [openssl] Error 1
  dkaufman make[1]: Leaving directory 
`/d/CYGWIN/ssl097-1213/openssl-0.9.7-stable-SNAP-20021213/apps'
  dkaufman make: *** [sub_all] Error 1
 
  Hmm, if you do something like 'nm libcrypto.a', can you see the symbol
  DES_SPtrans anywhere?  It should be part of ecb_enc.obj...
 
 The torture never stops. It surely have everything to do with DES
 PIC-ification. I'll look into it during the day and I'm pretty sure the
 fix will be in tonight snapshot. A.

Checkout CVS or wait till tonight (openssl.org night:-) and pull the
snapshot. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Cygwin compilation fails with 0.9.7-stable

2002-12-15 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Sun, 15 Dec 
2002 01:20:33 -0800 (PST), Doug Kaufman [EMAIL PROTECTED] said:

dkaufman It has _DES_SPtrans, but not DES_SPtrans. Results of nm follow:

Ah, C compilers do that, that's true...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Make depend fails for gcc (0.9.6h)

2002-12-15 Thread Corinna Vinschen
On Sun, Dec 15, 2002 at 01:31:52AM -0800, Doug Kaufman wrote:
 I just compiled openssl-0.9.6h (from CVS) with Cygwin. I configured
 with no-idea no-rc5 no-mdc2 no-shared. Make depend fails because
 Cygwin has no program named makedepend, which is called by
 util/domd. I borrowed the domd from 0.9.7, which has a provision for
 gcc being the makedepend program, and the rest of the compilation went
 fine, including make test and make install. I am not sure I see
 a simple fix, since in 0.9.7 the Configure script determines if the
 makedepend program should be gcc or not. Do we need to put this in the
 Configure script and modify Makefile.org and util/domd accordingly?
 
 I presume that this applies to any gcc compilation where there is no
 separate makedepend program.
Doug

`makedepend' is typically part of the XFree86 package, in Cygwin as
well as on Linux systems.  Just install the Cygwin XFree86 package.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Make depend fails for gcc (0.9.6h)

2002-12-15 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Sun, 15 Dec 2002 12:02:34 
+0100, Corinna Vinschen [EMAIL PROTECTED] said:

vinschen `makedepend' is typically part of the XFree86 package, in Cygwin as
vinschen well as on Linux systems.  Just install the Cygwin XFree86 package.

I must admit it would be a little silly to install XFree86 just to get
hold of makedepend.

(and it's beyond me why makedepend still hasn't become a separate
package, but that's not your fault)

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Make depend fails for gcc (0.9.6h)

2002-12-15 Thread Corinna Vinschen
On Sun, Dec 15, 2002 at 12:58:18PM +0100, Richard Levitte - VMS Whacker wrote:
 In message [EMAIL PROTECTED] on Sun, 15 Dec 2002 12:02:34 
+0100, Corinna Vinschen [EMAIL PROTECTED] said:
 
 vinschen `makedepend' is typically part of the XFree86 package, in Cygwin as
 vinschen well as on Linux systems.  Just install the Cygwin XFree86 package.
 
 I must admit it would be a little silly to install XFree86 just to get
 hold of makedepend.
 
 (and it's beyond me why makedepend still hasn't become a separate
 package, but that's not your fault)

You can't rely on it's existance and that's not a Cygwin problem.

It's just that most today's Linux/Unix installations have X installed
by default so you'll never see that problem.  Just curious:  What
about Apple's OS X?  It has no X so it probably has no makedepend, too.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [CVS] OpenSSL: openssl Makefile.org

2002-12-15 Thread Richard Levitte - VMS Whacker
Whoaa there, how does that change work when the compiler is *not* GNU?

In message [EMAIL PROTECTED] on Sun, 15 Dec 2002 
16:27:54 +0100 (CET), Andy Polyakov [EMAIL PROTECTED] said:

appro   Log:
appro Another Solaris shared build clean-up. This is not actually needed if one
appro uses WorkShop C. It's gcc driver that brings copy of libgcc.a into .so
appro otherwise. In case you wonder what it's -Wl,-z... and not just -z. Problem
appro is that gcc driver apparently omits all -z options but -z text. Don't ask
appro me why. I'm not committing corresponding workaround into the HEAD as
appro Makefile.shared reportedly needs even more work...
appro 
appro   Summary:
appro RevisionChanges Path
appro 1.154.2.41  +2  -1  openssl/Makefile.org
appro   
appro 
appro   Index: openssl/Makefile.org
appro   
appro   $ cvs diff -u -r1.154.2.40 -r1.154.2.41 Makefile.org
appro   --- openssl/Makefile.org   15 Dec 2002 06:45:46 -  1.154.2.40
appro   +++ openssl/Makefile.org   15 Dec 2002 15:27:53 -  1.154.2.41
appro   @@ -360,7 +360,8 @@
approset -x; ${CC} ${SHARED_LDFLAGS} -G -dy -z text \
appro  -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
appro  -h lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
appro   -  -z allextract lib$$i.a $$libs ${EX_LIBS} -lc ) || exit 
1; \
appro   +  -Wl,-z,allextract lib$$i.a -Wl,-z,defaultextract \
appro   +  $$libs ${EX_LIBS} -lc ) || exit 1; \
appro  libs=$$libs -l$$i; \
appro  done; \
appro  fi

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [CVS] OpenSSL: openssl Makefile.org

2002-12-15 Thread Andy Polyakov
 Whoaa there, how does that change work when the compiler is *not* GNU?

It works *perfectly* with vendor compiler! Trust me:-) A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [CVS] OpenSSL: openssl Makefile.org

2002-12-15 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Sun, 15 Dec 2002 20:43:46 +0100, Andy 
Polyakov [EMAIL PROTECTED] said:

appro  Whoaa there, how does that change work when the compiler is *not* GNU?
appro 
appro It works *perfectly* with vendor compiler! Trust me:-) A.

Really?  They understand -Wl?  I thought that was the hight of GNU
specificness (I know, not a real word.  Just understand it, please).

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [CVS] OpenSSL: openssl Makefile.org

2002-12-15 Thread Andy Polyakov
 appro  Whoaa there, how does that change work when the compiler is *not* GNU?
 appro
 appro It works *perfectly* with vendor compiler! Trust me:-) A.
 
 Really?  They understand -Wl?

Yes. Well, I can tell for version 3, but even WorkShop C 4 understands
-Wl. There is a whole bunch of compiler drivers that understand -Wl,
MIPSpro C does, Compaq C does, HP C does... In fact I can't think of one
that does *not*... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [CVS] OpenSSL: openssl Makefile.org

2002-12-15 Thread Andy Polyakov
  appro  Whoaa there, how does that change work when the compiler is *not* GNU?
  appro
  appro It works *perfectly* with vendor compiler! Trust me:-) A.
 
  Really?  They understand -Wl?
 
 Yes. Well, I can tell for version 3,
   ^^^ I meant I can *not* tell for for version 3. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Bug in openssl-0.9.7-stable install_docs (head3)

2002-12-15 Thread Doug Kaufman
I know that the problem of head3 in the pod files has been brought up
before, but I thought it had been resolved. Doing make install_docs,
using the latest 0.9.7-stable files from cvs, I get an error in
processing doc/crypto/engine.pod, related to head3. The man page is
created, but is truncated at the first head3 in the pod file. This is
the only file where I see the problem. The error message that I get is:

installing man3/engine.3
Can't locate object method cmd_head3 via package Pod::Man at \
/usr/local/lib/perl5/5.6.0/Pod/Man.pm line 463, GEN0 line 191.

The engine.pod file is dated 4 August 2002.
Doug

-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Bug in openssl-0.9.7-stable install_docs (head3)

2002-12-15 Thread Geoff Thorpe
* Doug Kaufman ([EMAIL PROTECTED]) wrote:
 I know that the problem of head3 in the pod files has been brought up
 before, but I thought it had been resolved. Doing make install_docs,
 using the latest 0.9.7-stable files from cvs, I get an error in
 processing doc/crypto/engine.pod, related to head3. The man page is
 created, but is truncated at the first head3 in the pod file. This is
 the only file where I see the problem. The error message that I get is:
 
 installing man3/engine.3
 Can't locate object method cmd_head3 via package Pod::Man at \
 /usr/local/lib/perl5/5.6.0/Pod/Man.pm line 463, GEN0 line 191.

Yes, this was left in limbo a bit. I'm of the mind that as far as pod
manipulations go, we should catch up with the later perl versions
that allow up to 4 levels of 'head'er. Ie. update our bundled version of
pod2man, and use that if the system's version is too old. However,
others had suggested we stick with the two levels offered by the (not
yet obsolete) version of Perl most people have. The argument seems to be
between the value of the pod files themselves (ie. people wanting to
manually convert them to html, latex, or whatever) and the improvements
possible in the man pages openssl generates from those pods. My opinion
is that the man pages generated by make install_docs is all that
matters w.r.t. version choices, and if others want to use the pod files
directly they can obtain versions of the pod tools that can handle
them.

I think with 0.9.7 in beta, I will try to replace the =head3 items
with something else in the 0.9.7 branch, but leave it as-is in the cvs
HEAD until we can get some definitive decision on how to proceed.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #401] Bug in openssl-0.9.7-stable install_docs (head3)

2002-12-15 Thread [EMAIL PROTECTED] via RT

I know that the problem of head3 in the pod files has been brought up
before, but I thought it had been resolved. Doing make install_docs,
using the latest 0.9.7-stable files from cvs, I get an error in
processing doc/crypto/engine.pod, related to head3. The man page is
created, but is truncated at the first head3 in the pod file. This is
the only file where I see the problem. The error message that I get is:

installing man3/engine.3
Can't locate object method cmd_head3 via package Pod::Man at \
/usr/local/lib/perl5/5.6.0/Pod/Man.pm line 463, GEN0 line 191.

The engine.pod file is dated 4 August 2002.
Doug

-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #373] Fw: is SSL_CTX_new() thread safe (on win32) ?

2002-12-15 Thread Louis Solomon [SteelBytes] via RT

yea, I think that patch should be ok.

Louis Solomon
www.SteelBytes.com


- Original Message -
From: Richard Levitte - VMS Whacker via RT [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, December 13, 2002 9:35 AM
Subject: Re: [openssl.org #373] Fw: is SSL_CTX_new() thread safe (on win32)
?



 I can see that happening.  Would the following patch help?

 Index: ssl/ssl_ciph.c
 ===
 RCS file: /e/openssl/cvs/openssl/ssl/ssl_ciph.c,v
 retrieving revision 1.33.2.3
 diff -u -u -r1.33.2.3 ssl_ciph.c
 --- ssl/ssl_ciph.c 19 Jul 2002 19:53:02 - 1.33.2.3
 +++ ssl/ssl_ciph.c 12 Dec 2002 22:32:30 -
 @@ -751,7 +751,9 @@
   */
   if (rule_str == NULL) return(NULL);

 + CRYPTO_w_lock(CRYPTO_LOCK_SSL);
   if (init_ciphers) load_ciphers();
 + CRYPTO_w_unlock(CRYPTO_LOCK_SSL);

   /*
   * To reduce the work to do we only want to process the compiled


 In message [EMAIL PROTECTED] on Mon,  2 Dec 2002
09:09:25 +0100 (MET), Louis Solomon [SteelBytes] via RT [EMAIL PROTECTED]
said:

 rt  ok,
 rt  here's the cause I think ...
 rt 
 rt  SSL_CTX_new(...)
 rt  {
 rt  ...
 rt  ssl_create_cipher_list(...)
 rt  ...
 rt  }
 rt 
 rt  static int init_ciphers=1;
 rt 
 rt  ssl_create_cipher_list(...)
 rt  {
 rt  ...
 rt  if (init_ciphers) load_ciphers();
 rt  ...
 rt  ssl_cipher_get_disabled()
 rt  ...
 rt  }
 rt 
 rt  load_ciphers()
 rt  {
 rt  init_ciphers  = 0;
 rt  ... // mark_1
 rt  init ssl_cipher_methods[]
 rt  ...
 rt  }
 rt 
 rt  ssl_cipher_get_disabled()
 rt  {
 rt  ...
 rt  use ssl_cipher_methods[]  // mark_2
 rt  ...
 rt  }
 rt 
 rt  consider this:
 rt  thread_1 calls SSL_CTX_new() and reaches mark_1
 rt  a context switch happens (thread_1 stalls, and thread_2 becomes
 rt active)
 rt  thread_2 calls SSL_CTX_new() and reaches mark_2
 rt 
 rt  thread_2 will be trying to read from ssl_cipher_methods which is
 rt  uninitialised !!
 rt 
 rt  any one care to fix the 0.9.7 beta ? (or 0.9.6g)
 rt 
 rt  Louis Solomon
 rt  www.SteelBytes.com

 --
 Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
 Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
 \  SWEDEN   \ or +46-708-26 53 44
 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
 Member of the OpenSSL development team: http://www.openssl.org/

 Unsolicited commercial email is subject to an archival fee of $400.
 See http://www.stacken.kth.se/~levitte/mail/ for more info.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #373] Fw: is SSL_CTX_new() thread safe (on win32) ?

2002-12-15 Thread Geoff Thorpe
* Louis Solomon [SteelBytes] via RT ([EMAIL PROTECTED]) wrote:
 
 yea, I think that patch should be ok.

  + CRYPTO_w_lock(CRYPTO_LOCK_SSL);
if (init_ciphers) load_ciphers();
  + CRYPTO_w_unlock(CRYPTO_LOCK_SSL);

Is this one of those performance-critical cases were you should run a
test outside the lock first? Ie.

   if (init_ciphers)
   {
   CRYPTO_w_lock(CRYPTO_LOCK_SSL);
   if (init_ciphers) load_ciphers();
   CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
   }

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



[openssl.org #373] Fw: is SSL_CTX_new() thread safe (on win32) ?

2002-12-15 Thread Richard Levitte via RT

The patch was confirmed today, and thereby committed.  This ticket is now resolved.

-- 
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: [openssl.org #373] Fw: is SSL_CTX_new() thread safe (on win32)?

2002-12-15 Thread Richard Levitte - VMS Whacker
In message [EMAIL PROTECTED] on Sun, 15 Dec 2002 21:49:02 
-0500, Geoff Thorpe [EMAIL PROTECTED] said:

geoff Is this one of those performance-critical cases were you should run a
geoff test outside the lock first? Ie.
geoff 
geoffif (init_ciphers)
geoff{
geoffCRYPTO_w_lock(CRYPTO_LOCK_SSL);
geoffif (init_ciphers) load_ciphers();
geoffCRYPTO_w_unlock(CRYPTO_LOCK_SSL);
geoff}

Good point.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]