[openssl.org #1996] Probably a type conflict (BLOCK) in upcoming 1.0 version
Hi all, NetBSD5 (development version) is currently distributed with 'OpenSSL 1.1.0-dev 10 Jul 2009', which breaks compatibility with perl (detected when updating Crypt::SSLeay): /usr/pkg/bin/perl /usr/pkg/lib/perl5/vendor_perl/5.10.0/ExtUtils/xsubpp -typemap /usr/pkg/lib/perl5/5.10.0/ExtUtils/typemap -typemap typemap SSLeay.xs SSLeay.xsc mv SSLeay.xsc SSLeay.c cc -c -I/usr/include/openssl -fno-strict-aliasing -pipe -I/usr/pkg/include -O2 -O2 -fno-strict-aliasing -I/usr/pkg/include -I/usr/include -I/usr/pkg/include -I/usr/include-DVERSION=\0.57\ -DXS_VERSION=\0.57\ -DPIC -fPIC -I/usr/pkg/lib/perl5/5.10.0/x86_64-netbsd-thread-multi/CORE SSLeay.c In file included from /usr/include/openssl/crypto.h:129, from /usr/include/openssl/comp.h:5, from /usr/include/openssl/ssl.h:149, from crypt_ssleay_version.h:1, from SSLeay.xs:25: /usr/include/openssl/safestack.h:131: error: conflicting types for 'BLOCK' /usr/pkgsrc/security/p5-Crypt-SSLeay/work/.buildlink/lib/perl5/5.10.0/x86_64-netbsd-thread-multi/CORE/perl.h:2360: error: previous declaration of 'BLOCK' was here *** Error code 1 I checked both files, both declare BLOCK as (different) type. Perl5 declare this even in 5.8 (I didn't check earlier versions), but OpenSSL is not using it in 0.9.8. Maybe you should choose a different name for the memory block type (e.g. MEMBLOCK, BLOB, ARRAY - what ever you mean). BTW: When I'm already writing - did someone of you gave feedback regarding the OpenSSL module in CPAN to Stefan Traby? It's a big deficit when it couldn't came back because of the naming conflict. Best regards, Jens __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1997] [PATCH] DTLS timeout handling bug
This patch fixes the timeout handling. The method dtls1_get_timeout()
was intended to determine the next handshake message timeout when
using select() calls, to set their timeout. This method is renamed to
DTLSv1_get_timeout(), to fit the common naming scheme and the
declaration is moved. It was declared in the wrong file, so the user
was unable to use it. Additionally, the timeout handling is moved to
the method DTLSv1_handle_timeout(), which can be called by the user
when a select() timer expires. Until now expired timers were handled
not until a SSL_read() is called. This is a problem when using
select() on the reading socket, because no call of SSL_read() is done
before data from the peer arrived.
The test programs s_server and s_client are also modified to make use
of the new timeout handling to fully support timeouts.
--- apps/s_client.c 30 Jun 2009 15:56:35 - 1.125
+++ apps/s_client.c 27 Jul 2009 12:28:55 -
@@ -411,6 +411,7 @@
BIO *sbio;
char *inrand=NULL;
int mbuf_len=0;
+ struct timeval timeout, *timeoutp;
#ifndef OPENSSL_NO_ENGINE
char *engine_id=NULL;
char *ssl_client_engine_id=NULL;
@@ -1196,6 +1197,12 @@
FD_ZERO(readfds);
FD_ZERO(writefds);
+ if ((SSL_version(con) == DTLS1_VERSION)
+ (DTLSv1_get_timeout(con, timeout) != NULL))
+ timeoutp = timeout;
+ else
+ timeoutp = NULL;
+
if (SSL_in_init(con) !SSL_total_renegotiations(con))
{
in_init=1;
@@ -1300,7 +1307,7 @@
if(!i (!((_kbhit()) ||
(WAIT_OBJECT_0 ==
WaitForSingleObject(GetStdHandle(STD_INPUT_HANDLE), 0))) || !
read_tty) ) continue;
#endif
} else i=select(width,(void *)readfds,(void
*)writefds,
-NULL,NULL);
+NULL,timeoutp);
}
#elif defined(OPENSSL_SYS_NETWARE)
if(!write_tty) {
@@ -1310,7 +1317,7 @@
i=select(width,(void *)readfds,(void
*)writefds,
NULL,tv);
} else i=select(width,(void *)readfds,(void
*)writefds,
- NULL,NULL);
+ NULL,timeoutp);
}
#elif defined(OPENSSL_SYS_BEOS_R5)
/* Under BeOS-R5 the situation is similar to DOS */
@@ -1328,12 +1335,12 @@
if (!i (stdin_set != 1 || !read_tty))
continue;
} else i=select(width,(void *)readfds,(void
*)writefds,
-NULL,NULL);
+NULL,timeoutp);
}
(void)fcntl(fileno(stdin), F_SETFL, 0);
#else
i=select(width,(void *)readfds,(void *)writefds,
-NULL,NULL);
+NULL,timeoutp);
#endif
if ( i 0)
{
@@ -1344,6 +1351,11 @@
}
}
+ if ((SSL_version(con) == DTLS1_VERSION)
DTLSv1_handle_timeout(con) 0)
+ {
+ BIO_printf(bio_err,TIMEOUT occured\n);
+ }
+
if (!ssl_pending FD_ISSET(SSL_get_fd(con),writefds))
{
k=SSL_write(con,(cbuf[cbuf_off]),
--- apps/s_server.c 30 Jun 2009 15:56:35 - 1.140
+++ apps/s_server.c 27 Jul 2009 12:28:55 -
@@ -1750,6 +1750,7 @@
unsigned long l;
SSL *con=NULL;
BIO *sbio;
+ struct timeval timeout, *timeoutp;
#if defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_MSDOS) ||
defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_BEOS_R5)
struct timeval tv;
#endif
@@ -1919,7 +1920,19 @@
read_from_terminal = 1;
(void)fcntl(fileno(stdin), F_SETFL, 0);
#else
- i=select(width,(void *)readfds,NULL,NULL,NULL);
+ if ((SSL_version(con) == DTLS1_VERSION)
+ (DTLSv1_get_timeout(con, timeout) != NULL))
+ timeoutp = timeout;
+ else
+ timeoutp = NULL;
+
+ i=select(width,(void *)readfds,NULL,NULL,timeoutp);
+
+ if ((SSL_version(con) == DTLS1_VERSION)
DTLSv1_handle_timeout(con) 0)
+ {
+
[openssl.org #1996] Probably a type conflict (BLOCK) in upcoming 1.0 version
[rehs...@googlemail.com - Mon Jul 27 09:24:08 2009]: I checked both files, both declare BLOCK as (different) type. Perl5 declare this even in 5.8 (I didn't check earlier versions), but OpenSSL is not using it in 0.9.8. Maybe you should choose a different name for the memory block type (e.g. MEMBLOCK, BLOB, ARRAY - what ever you mean). This has now been changed to OPENSSL_BLOCK. Let me know if this fixes your problem. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1987] Definition of STRING conflicts with ntsecapi.h
[c...@savagexi.com - Mon Jul 20 11:01:32 2009]: I assume other programs that use openssl and ntsecapi will also fail to compile. Any chance these generic typedefs can be changed to something like OPENSSL_STRING and OPENSSL_CSTRING? This has been changed to OPENSSL_STRING etc. Please check the latest snapshots resolve this issue. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH] SHA512 ROTR macro fix for PowerPC using LP32 model
Hi,
I am new to the list, so apologies if I fail to follow any of the ground
rules.
I just ran into a bug where SHA384/512 were not being calculated
correctly on the Cell processor. I tracked it down to the definition of
the ROTR macro, which is assuming a 64 bit long, but in this case the
compiler is using the LP32 model so long is 32 bits and the values were
being truncated. Here is the patch I did that fixes the problem:
--- sha512.c2009-07-27 15:04:52.546574000 -0700
+++ sha512.c2009-07-27 15:08:07.373452100 -0700
@@ -344,7 +344,7 @@
((SHA_LONG64)hi)32|lo;})
# endif
# elif (defined(_ARCH_PPC) defined(__64BIT__)) ||
defined(_ARCH_PPC64)
-# define ROTR(a,n) ({ unsigned long ret; \
+# define ROTR(a,n) ({ SHA_LONG64 ret; \
asm (rotrdi %0,%1,%2 \
: =r(ret) \
: r(a),K(n)); ret; })
If it is desirable to not use SHA_LONG64 in the macro, another option
would be to test for the __LP32__ preprocessor symbol and use unsigned
long long when that is defined.
I am using OpenSSL 0.9.8k, but looking at the latest snapshot it seems
this problem has not been fixed yet.
Questions or feedback welcome.
Thanks,
Benbuck Nason
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH] SHA512 ROTR macro fix for PowerPC using LP32 model
Don't worry 'bout it too much.
Could you please create that as a .diff file and attach it to an email
to r...@openssl.org? The rt system creates a case that can be tracked.
-Kyle H
On Mon, Jul 27, 2009 at 3:26 PM, Ben Nasonbna...@netflix.com wrote:
Hi,
I am new to the list, so apologies if I fail to follow any of the ground
rules.
I just ran into a bug where SHA384/512 were not being calculated
correctly on the Cell processor. I tracked it down to the definition of
the ROTR macro, which is assuming a 64 bit long, but in this case the
compiler is using the LP32 model so long is 32 bits and the values were
being truncated. Here is the patch I did that fixes the problem:
--- sha512.c 2009-07-27 15:04:52.546574000 -0700
+++ sha512.c 2009-07-27 15:08:07.373452100 -0700
@@ -344,7 +344,7 @@
((SHA_LONG64)hi)32|lo; })
# endif
# elif (defined(_ARCH_PPC) defined(__64BIT__)) ||
defined(_ARCH_PPC64)
-# define ROTR(a,n) ({ unsigned long ret; \
+# define ROTR(a,n) ({ SHA_LONG64 ret; \
asm (rotrdi %0,%1,%2 \
: =r(ret) \
: r(a),K(n)); ret; })
If it is desirable to not use SHA_LONG64 in the macro, another option
would be to test for the __LP32__ preprocessor symbol and use unsigned
long long when that is defined.
I am using OpenSSL 0.9.8k, but looking at the latest snapshot it seems
this problem has not been fixed yet.
Questions or feedback welcome.
Thanks,
Benbuck Nason
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
