[openssl.org #457] bug report: BIO_socket_nbio() can't set socket to non-blocking
bug report: openssl operating system: HP-UX11 openssl version 0.9.6b, 0.96g and probably 0.7 too. configuration options:./Configure hpux64-parisc-cc shared no-idea Description: BIO_socket_nbio() fails to set sockets to non-blocking mode. The call succeeds but the socket is still blocking I have noticed that BIO_socket_nbio() calls BIO_socket_ioctl() unsing FIONBIO. This ioctl, according to it's man page, takes one argument: a pointer to int, but the BIO_socket_ioctl() uses a pointer to long as the argument. This will result in that the os will only read the 32 most significant bits of the 64 bit long value that is set to 0 or 1 by BIO_socket_nbio(). These bits are always 0 and the call will always set the socket to blocking mode. (If I patch BIO_socket_ioctl() to send a pointer to int instead the calls to BIO_socket_nbio() work as expected.) Regards /Magnus Lind __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #437] bad instructions in CHANGES for platform-dependent builds
Please test the latest snapshot and answer the questions below. I'm skipping VPATH discussion for now. I'd like to resolve this ticket soon. [levitte - Fri Jan 10 16:52:20 2003]: If you just leave out the -o -type l you won't make any of the links, and the include/openssl directory will be empty, which will fail. Only if you don't configure in your build tree. Why should you leave that out? Of course your source directory needs to be absent any residual configuration -- which would cause the script to make links to files that would be created by Configure and might then cause subsequent Configures to update the source tree version. What files is Configure creating that you're worried about and that 'make clean' doesn't take care of? To be very exact, what in this sequence doesn't work? - make the object tree with soft links to the source tree files. - make -f Makefile.org clean - ./config -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #458] 'openssl x509' not quite working...
I just test, with OpenSSL 0.9.7a-dev (fresh checkout), the command to generate a self-signed cerificate according to the example in x509.pod: openssl x509 -in cert.pem -addtrust sslclient \ -alias Steve's Class 1 CA -out trust.pem I expected it to fail because it wouldn't find those files. However, the error was more of an unexpected one: Invalid trust object value sslclient And I can't quite blame it, I can't really see where that object would find itself into the object database. What am I missing? I'm filing this as a bug, as I suspect that's exactly what it is. -- 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 #458] 'openssl x509' not quite working...
Richard Levitte - VMS Whacker via RT wrote: I just test, with OpenSSL 0.9.7a-dev (fresh checkout), the command to generate a self-signed cerificate according to the example in x509.pod: openssl x509 -in cert.pem -addtrust sslclient \ -alias Steve's Class 1 CA -out trust.pem I expected it to fail because it wouldn't find those files. However, the error was more of an unexpected one: Invalid trust object value sslclient And I can't quite blame it, I can't really see where that object would find itself into the object database. What am I missing? I think it's a typo. From 'man x509' : /snip -addtrust arg adds a trusted certificate use. Any object name can be used here but currently only clientAuth (SSL client use), serverAuth (SSL server use) and emailProtection (S/MIME email) are used. Other OpenSSL applications may define additional uses. /snap = I guess the example should be: openssl x509 -in cert.pem -addtrust clientAuth \ -alias Steve's Class 1 CA -out trust.pem Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #426] HP-UX build problems with 0.9.7
On Tue, Dec 31, 2002 at 01:21:09PM +0100, Marko Asplund via RT wrote: 2) error messages during 'make depend' when not using gcc and makedepend is installed on the system (HP Ansi C Developer's Bundle, imake package). seems like this version of makedepend is not supported. maybe Configure should check that the system makedepend is suitable for building OpenSSL before using it. ... ../util/domd .. -MD makedepend -- -DOPENSSL_THREADS -D_REENTRANT -DDSO_DL -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -I. -I.. -I../include -DOPENSSL_NO_IDEA -- cryptlib.c mem.c mem_clr.c mem_dbg.c cversion.c ex_data.c tmdiff.c cpt_err.c ebcdic.c uid.c o_time.c cryptlib.c:433: !defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE 199309L) ^--- expecting ) Hmm. I have tried to reproduce this behaviour on HP-UX 10.20. serv01 21: which makedepend /opt/imake/bin/makedepend serv01 23: what /opt/imake/bin/makedepend /opt/imake/bin/makedepend: X Window System, Version 11 R6+ HP-UX B.10.20.00 January 2001 Patch Release (build date: Mon Jan 22 19:09:38 IST 2001) The CFLAGS seem to be passed properly... -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5
I've analysed this further and the cause seems to be that it bcc 5.5 complains about taking the address of a structure that doesn't have a complete definition. For example the following wont compile: typedef struct FOO_st FOO; extern FOO bar; FOO *pbar; pbar = bar; but it has no problems on other compilers. There are several possible workarounds for this. One is to include the complete definition whenever some_item is used, another is to change things so some_item is of type ASN1_ITEM * instead of ASN1_ITEM. However the easiest is to use the same options as VC++ which has an unrelated problem with initializing structures containing pointers to structures in DLLs. If you add EXPORT_VAR_AS_FN in the BCC-32 entry in Configure as in the VC-WIN32 entry it seems to compile OK and passes all the tests. I'll check in this fix soon. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #458] 'openssl x509' not quite working...
The example was incorrect. I've committed a change. This ticket is now resolved. Thanks to Nils Larsch for helping me figure this one out. [[EMAIL PROTECTED] - Tue Jan 14 12:56:55 2003]: I just test, with OpenSSL 0.9.7a-dev (fresh checkout), the command to generate a self-signed cerificate according to the example in x509.pod: openssl x509 -in cert.pem -addtrust sslclient \ -alias Steve's Class 1 CA -out trust.pem I expected it to fail because it wouldn't find those files. However, the error was more of an unexpected one: Invalid trust object value sslclient And I can't quite blame it, I can't really see where that object would find itself into the object database. What am I missing? I'm filing this as a bug, as I suspect that's exactly what it is. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5
In message [EMAIL PROTECTED] on Tue, 14 Jan 2003 14:49:31 +0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said: rt I've analysed this further and the cause seems to be that it bcc 5.5 rt complains about taking the address of a structure that doesn't have a rt complete definition. rt rt For example the following wont compile: rt rt typedef struct FOO_st FOO; rt rt extern FOO bar; rt rt FOO *pbar; rt rt pbar = bar; rt rt but it has no problems on other compilers. I believe this is a compiler bug, which should be reported back to Borland (unless they have a newer version of bcc that works correctly). rt If you add EXPORT_VAR_AS_FN in the BCC-32 entry in Configure as in the rt VC-WIN32 entry it seems to compile OK and passes all the tests. rt rt I'll check in this fix soon. Sounds reasonable. -- 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]
[PATCH] pkcs#11 engine for openssl 0.9.7 0.9.6h
Hello Richard, Richard Levitte via RT wrote: It's unfortunate that cryptoki.h is GPLd, or I would put it in our contribution area. GPL is not compatible with the OpenSSL license. Is it possible to get a different cryptoki.h? I got the original cryptoki.h which is not GPLd from RSA and is a sample for Windows environment. I have added necessary changes for Unix-like platforms. Also, is conf.h really necssary? You're absolutely right, conf.h is not necessary. I take it off. I'm willing to do the transformation needed for this bundle to work properly within OpenSSL. So, you can find attached to this mail updates taking in account your advice. Cheers, Afchine Madjlessi __ [EMAIL PROTECTED] Bull TrustWay RD, France http://www.servers.bull.com/trustway trustway-pkcs11-openssl-0.9.7.patch.gz Description: GNU Zip compressed data trustway-pkcs11-openssl-engine-0.9.6h.patch.gz Description: GNU Zip compressed data
Re: [openssl.org #426] HP-UX build problems with 0.9.7
On Tue, 14 Jan 2003, Lutz Jaenicke via RT wrote: On Tue, Dec 31, 2002 at 01:21:09PM +0100, Marko Asplund via RT wrote: 2) error messages during 'make depend' when not using gcc and makedepend is installed on the system (HP Ansi C Developer's Bundle, imake package). seems like this version of makedepend is not supported. maybe Configure should check that the system makedepend is suitable for building OpenSSL before using it. ... ../util/domd .. -MD makedepend -- -DOPENSSL_THREADS -D_REENTRANT -DDSO_DL -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed +Olibcalls -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -I. -I.. -I../include -DOPENSSL_NO_IDEA -- cryptlib.c mem.c mem_clr.c mem_dbg.c cversion.c ex_data.c tmdiff.c cpt_err.c ebcdic.c uid.c o_time.c cryptlib.c:433: !defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE 199309L) ^--- expecting ) Hmm. I have tried to reproduce this behaviour on HP-UX 10.20. serv01 21: which makedepend /opt/imake/bin/makedepend serv01 23: what /opt/imake/bin/makedepend /opt/imake/bin/makedepend: X Window System, Version 11 R6+ HP-UX B.10.20.00 January 2001 Patch Release (build date: Mon Jan 22 19:09:38 IST 2001) The CFLAGS seem to be passed properly... this is what 'what makedepend' said on my system (at the time of the above report): 109] % what /opt/imake/bin/makedepend /opt/imake/bin/makedepend: X Window System, Version 11 R6+ HP-UX B.11.00.00 +O2 (build date: Wed Sep 17 02:43:56 PDT 1997) i just searched ITRC and found that this was a known problem which PHSS_22947 patch would fix. here's a quote from the patch README: 12. While parsing int literals, L suffix is not handled correctly by makedepend. http://www4.itrc.hp.com/service/patch/patchDetail.do?patchid=PHSS_22947context=hpux:800:11:00 installation of this patch does make the makedepend error messages go away. best regards, -- aspahttp://www.kronodoc.fi/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #459] [bug] DSA BN_init() bugs in 0.9.6h and 0.9.7
I sent this to openssl-dev previously, but I think it got lost in the noise there (since it didn't go through rt). In OpenSSL 0.9.6h, there are a couple of BN_init() bugs in crypto/dsa/dsa_ossl.c. The BN_init() calls in question are in the functions: dsa_do_sign()(lines 113-114) dsa_sign_setup() (line 187) dsa_do_verify() (lines 239-241) In all cases, the BN_init() calls need to be moved before the first if statement (so that they are the first functions executed). As written, if you goto the err label before doing the BN_init() call you could cause a crash when you attempt to free a garbage pointer. The same bugs exist in 0.9.7 but on slightly different line numbers. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #426] HP-UX build problems with 0.9.7
On Tue, Jan 14, 2003 at 05:12:19PM +0100, Marko Asplund via RT wrote: this is what 'what makedepend' said on my system (at the time of the above report): 109] % what /opt/imake/bin/makedepend /opt/imake/bin/makedepend: X Window System, Version 11 R6+ HP-UX B.11.00.00 +O2 (build date: Wed Sep 17 02:43:56 PDT 1997) i just searched ITRC and found that this was a known problem which PHSS_22947 patch would fix. here's a quote from the patch README: 12. While parsing int literals, L suffix is not handled correctly by makedepend. http://www4.itrc.hp.com/service/patch/patchDetail.do?patchid=PHSS_22947context=hpux:800:11:00 installation of this patch does make the makedepend error messages go away. Ok. Therefore: 1) (hpux-parisc2-cc no-asm) seems to be a compiler/optimizer bug. I have added an appropriate remark to the PROBLEMS file. 2) makedepend problem on HP-UX 11 is fixed by installing patch PHSS_22947 3) (parisc2.s contains code that is position independent) is resolved by a change checked in by Andy Polyakov. I therefore close this ticket now. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++5.5
Richard Levitte - VMS Whacker via RT wrote: In message [EMAIL PROTECTED] on Tue, 14 Jan 2003 14:49:31 +0100 (MET), Stephen Henson via RT [EMAIL PROTECTED] said: rt I've analysed this further and the cause seems to be that it bcc 5.5 rt complains about taking the address of a structure that doesn't have a rt complete definition. rt rt For example the following wont compile: rt rt typedef struct FOO_st FOO; rt rt extern FOO bar; rt rt FOO *pbar; rt rt pbar = bar; rt rt but it has no problems on other compilers. I believe this is a compiler bug, which should be reported back to Borland (unless they have a newer version of bcc that works correctly). It is a compiler bug, definitely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++5.5
Yes that's what I thought. Any ANSI C experts care to comment on whether that is legal or not? It's as legal as this: extern int foo(int); int (*fp)(int) = foo; :) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5
Yes that's what I thought. Any ANSI C experts care to comment on whether that is legal or not? It's as legal as this: extern int foo(int); int (*fp)(int) = foo; :) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ASN1_TIME inconsistent function behaviour / bug?
Working on code to read/process and create x509 certificates I encountered the following. The following code results in an ASN1_TIME structure with internal length field of 14 (date1-length =14). date1 = ASN1_TIME_new(); ASN1_GENERALIZEDTIME_set_string(date1, 20020819093712); When extracting time out an existing certificate however with this date/time would result in a length field of 15 (date2-length = 15). ASN1_GENERALIZEDTIME *date2 = ASN1_TIME_to_generalizedtime (X509_get_notBefore(cert), NULL); Consequently ASN1_STRING_cmp(date1, date2) fails, although the strings are exactly the same, 14 characters that make up the date, followed by \0. Have I missed something or is there a bug somewhere? Paul __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #451] SX6 port
Andy Polyakov via RT wrote: + sx6, cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::, No optimization? Not even lousy -O? -g overrides any optimization you give, and i think there's a problem with the optimizer anyway because with default optimization, aes-128-cbc test fails. it's fine with -g. SIXTY_FOUR_BIT? SIXTY_FOUR_BIT aims ILP32 ABIs implemented on 64-bit CPUs, N32 ABI on IRIX 6 is one example. If your sizeof(long)==8, then you should use SIXTY_FOUR_BIT_LONG. Please confirm. thank you for the note. yes, it should be SIXTY_FOUR_BIT_LONG. wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. [EMAIL PROTECTED], 651-605-9154 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1_TIME inconsistent function behaviour / bug?
On Tue, Jan 14, 2003, Paul Koster wrote: Working on code to read/process and create x509 certificates I encountered the following. The following code results in an ASN1_TIME structure with internal length field of 14 (date1-length =14). date1 = ASN1_TIME_new(); ASN1_GENERALIZEDTIME_set_string(date1, 20020819093712); When extracting time out an existing certificate however with this date/time would result in a length field of 15 (date2-length = 15). ASN1_GENERALIZEDTIME *date2 = ASN1_TIME_to_generalizedtime (X509_get_notBefore(cert), NULL); Consequently ASN1_STRING_cmp(date1, date2) fails, although the strings are exactly the same, 14 characters that make up the date, followed by \0. Have I missed something or is there a bug somewhere? Was this existing certificate created using OpenSSL? What does the time in this existing certificate look like? That is what length is reported by asn1parse on it. In particular does the certificate encoding include the trailing \0? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1_TIME inconsistent function behaviour / bug?
The following code results in an ASN1_TIME structure with internal length field of 14 (date1-length =14). date1 = ASN1_TIME_new(); ASN1_GENERALIZEDTIME_set_string(date1, 20020819093712); When extracting time out an existing certificate however with this date/time would result in a length field of 15 (date2-length = 15). ASN1_GENERALIZEDTIME *date2 = ASN1_TIME_to_generalizedtime (X509_get_notBefore(cert), NULL); Consequently ASN1_STRING_cmp(date1, date2) fails, although the strings are exactly the same, 14 characters that make up the date, followed by \0. Have I missed something or is there a bug somewhere? Was this existing certificate created using OpenSSL? No. The certificate was created with a java library (from bouncycastle.com I think). What does the time in this existing certificate look like? That is what length is reported by asn1parse on it. In particular does the certificate encoding include the trailing \0? The output of openssl asn1parse -inform DER cert.cer is: 165:d=3 hl=2 l= 13 prim: UTCTIME :020819093712Z May I assume that the Z stands for \0? And l=13 stands for a length of 13 which gives a length of 15 when the year is written as 2002? This clears things up a bit, but then may question is how date/time should be handled using openssl code. I'd like to be able to perform a compare operation (==, , ) on certificate notBefore and notAfter fields. Are there any 'normalization' functions available for example? Paul __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1_TIME inconsistent function behaviour / bug?
On Tue, Jan 14, 2003, Paul Koster wrote: The following code results in an ASN1_TIME structure with internal length field of 14 (date1-length =14). date1 = ASN1_TIME_new(); ASN1_GENERALIZEDTIME_set_string(date1, 20020819093712); When extracting time out an existing certificate however with this date/time would result in a length field of 15 (date2-length = 15). ASN1_GENERALIZEDTIME *date2 = ASN1_TIME_to_generalizedtime (X509_get_notBefore(cert), NULL); Consequently ASN1_STRING_cmp(date1, date2) fails, although the strings are exactly the same, 14 characters that make up the date, followed by \0. Have I missed something or is there a bug somewhere? Was this existing certificate created using OpenSSL? No. The certificate was created with a java library (from bouncycastle.com I think). What does the time in this existing certificate look like? That is what length is reported by asn1parse on it. In particular does the certificate encoding include the trailing \0? The output of openssl asn1parse -inform DER cert.cer is: 165:d=3 hl=2 l= 13 prim: UTCTIME :020819093712Z May I assume that the Z stands for \0? And l=13 stands for a length of 13 which gives a length of 15 when the year is written as 2002? No Z is the actual character 'Z'. Its a time zone but the various certificate standards say it should always be Z for GMT. This clears things up a bit, but then may question is how date/time should be handled using openssl code. I'd like to be able to perform a compare operation (==, , ) on certificate notBefore and notAfter fields. Are there any 'normalization' functions available for example? Both UTCTime and GeneralizedTime can be used to represent date/time, the Time type (with structure ASN1_TIME) is a combination of the two which uses whatever is appropriate. UTCTime can only represent years from 1950 to 2049 whereas GeneralizedTime can represent from to . So what you can do is check the type using ASN1_STRING_type(str) and interprete its contents accordingly. If however you just want to compare against a time_t value X509_cmp_time() will do the trick. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5
OK, since the consensus seems to be a compiler bug and a workaround has been checked in I'll resolve this ticket. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
That would certainly seem like a good first step. Have you traced into it at all? I.e. have you run with debug setup and seen a stack trace s.t. you know the function that is crashing and what variable is bad (a null pointer or something)? IF so, I may be able to provide the work around code. I haven't had time to recompile the debug version and run it in the debugger to see what is really happening. Doubt I'll get to it for quite a while, either. But I do know some of the common problems and, if I see the code that is generating faulty code I might see a simple revision. michael At 02:05 AM 1/14/2003 +0100, you wrote: [steve - Fri Jan 10 01:33:03 2003]: I've managed to download SP5 and the processor add on pack. With VC++ 6.0 and SP5 only it passes all tests. With VC++ 6.0, SP5 and processor add on it misbehaves and things like AES give invalid results. After playing around with various options it seems that disabling global optimization with /Og- (add to CFLAG in ntdll.mak) makes it pass the tests and AES works again. Disabling it with a #pragma in aes_core.c also fixes AES but from your description there are other problems too. Now I've got to work out how to uninstall this processor add on pack... Ugh, the only way to remove the processor add on pack seems to be a complete uninstall and reinstall. I think the best we can do with this compiler issue is to document the problem with the processor add on pack (in INSTALL.W32 and possibly the FAQ) and include the workaround. Adding /Og- in general seems to disable some quite extensive optimization and would be overkill because systems without the add on pack aren't affected. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
