need some clarification about the BN_LLONG define
All, some longer time ago I posted a patch to remove the BN_LLONG define for NetWare CLIB builds. This was for two reasons: I could remove the dependency on CodeWarrior's runtime library + I was able to build with gcc where I had no CLIB-based runtime at all. I assumed that the BN_LLONG define controls whether OpenSSL either uses 64-bit arith from the OS, or some own replacements; and compilation went fine without BN_LLONG defined. Some time later I found that the bnllong test at least produced another output as what I got with the LIBC builds where BN_LLONG is defined; but unfortunately I was very short with time, and my mail account was busted and even more worse I couldnt subscribe with my new account - so all these things held me up looking further into it. Now due to a couple of recent changes I see that currently all 3 branches HEAD, 1_0_0 and 0_9_8 are broken for NetWare, and one of these breaks is that compilation for CLIB does no longer work without having BN_LLONG defined with 0_9_8 branch: d1_pkt.c: In function `dtls1_read_bytes': d1_pkt.c:760: incompatible type for argument 3 of `dtls1_buffer_record' make[1]: *** [d1_pkt.o] Error 1 though branches 1_0_0 and HEAD compile fine; I think because the prototype is different: static int dtls1_buffer_record(SSL *s, record_pqueue *q, unsigned char *priority); while with 0_9_8 we have: static int dtls1_buffer_record(SSL *s, record_pqueue *q, PQ_64BIT priority); line 760 / 0_9_8 and line 803 / 1_0_0 and HEAD is: dtls1_buffer_record(s, (s-d1-buffered_app_data), 0); maybe the prototype from 1_0_0/HEAD needs backported to 0_9_8 branch? Then I would also like to get some clarification about the BN_LLONG define, and if its valid to compile without this define for a 32-bit platform? thanks, Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: need some clarification about the BN_LLONG define
On Sat, Jun 13, 2009, Guenter wrote: Now due to a couple of recent changes I see that currently all 3 branches HEAD, 1_0_0 and 0_9_8 are broken for NetWare, and one of these breaks is that compilation for CLIB does no longer work without having BN_LLONG defined with 0_9_8 branch: d1_pkt.c: In function `dtls1_read_bytes': d1_pkt.c:760: incompatible type for argument 3 of `dtls1_buffer_record' make[1]: *** [d1_pkt.o] Error 1 though branches 1_0_0 and HEAD compile fine; I think because the prototype is different: static int dtls1_buffer_record(SSL *s, record_pqueue *q, unsigned char *priority); while with 0_9_8 we have: static int dtls1_buffer_record(SSL *s, record_pqueue *q, PQ_64BIT priority); line 760 / 0_9_8 and line 803 / 1_0_0 and HEAD is: dtls1_buffer_record(s, (s-d1-buffered_app_data), 0); maybe the prototype from 1_0_0/HEAD needs backported to 0_9_8 branch? Then I would also like to get some clarification about the BN_LLONG define, and if its valid to compile without this define for a 32-bit platform? Yes it should be possible to compile without BN_LLONG and this shows the above code is broken. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
[maarten.litma...@cern.ch - Fri Jun 05 06:52:54 2009]: Dear OpenSSL developers, please have a look at the following bug about a bad interaction between mod_ssl and openssl 0.9.7, 0.9.8 and possibly higher versions when the server side supports more than 85 CAs: https://issues.apache.org/bugzilla/show_bug.cgi?id=46952 So far this has only caused problems for services whose certs were issued by the CERN CA, a standard Microsoft CA instance. The mod_ssl developer who responded thinks this might be a bug in openssl rather than mod_ssl: can you comment? This issue is steadily moving toward becoming a big nuisance for CERN and the projects it participates in, e.g. EGEE. For completeness, our problem is documented here: https://savannah.cern.ch/bugs/?48458 I can't see how anything could cause an issue with 85 CAs. The attached descriptions imply it might be a mod_ssl issue (not reproducible with s_server). I'd suggest trying OpenSSL 0.9.8k as well though because some code changes might have an effect in that area. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1943] [PROPOSAL] rename uni2asc asc2uni because of naming conflict
Renaming global functions on a stable branch isn't something we normally do due to binary compatibility issues. Could this stuff be conditional for Netware at least in 0.9.8? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1943] [PROPOSAL] rename uni2asc asc2uni because of naming conflict
Hi Steve, Stephen Henson via RT schrieb: Renaming global functions on a stable branch isn't something we normally do due to binary compatibility issues. Could this stuff be conditional for Netware at least in 0.9.8? sure, though I thought since the tests are anyway called by openssl-own scripts this wouldnt be an issue ... Also no idea yet how to do it conditional? Some hacking in the generated makefiles you have in mind? Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1943] [PROPOSAL] rename uni2asc asc2uni because of naming conflict
Hi Steve, Stephen Henson via RT schrieb: Renaming global functions on a stable branch isn't something we normally do due to binary compatibility issues. Could this stuff be conditional for Netware at least in 0.9.8? sure, though I thought since the tests are anyway called by openssl-own scripts this wouldnt be an issue ... Also no idea yet how to do it conditional? Some hacking in the generated makefiles you have in mind? Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1943] [PROPOSAL] rename uni2asc asc2uni because of naming conflict
Hi Steve, Guenter schrieb: sure, though I thought since the tests are anyway called by openssl-own scripts this wouldnt be an issue ... Also no idea yet how to do it conditional? Some hacking in the generated makefiles you have in mind? sorry, I had just the other bug in mind which Norm posted about renaming the tests. Sure, we can do the renaming of the functions #ifdef'd for OPENSSL_SYS_NETWARE, no prob. Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1943] [PROPOSAL] rename uni2asc asc2uni because of naming conflict
Hi Steve, Guenter schrieb: sure, though I thought since the tests are anyway called by openssl-own scripts this wouldnt be an issue ... Also no idea yet how to do it conditional? Some hacking in the generated makefiles you have in mind? sorry, I had just the other bug in mind which Norm posted about renaming the tests. Sure, we can do the renaming of the functions #ifdef'd for OPENSSL_SYS_NETWARE, no prob. Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
