[openssl.org #341] problems with make on jaguar mac os x 10.2
Hello OpenSL Team, After running a successful ./config --prefix=/usr --openssldir=/usr no-asm of openssl-0.9.6g, I tried to run the make. Here is the results: /usr/bin/ld: /usr/lib/libssl.dylib load command 8 unknown cmd field /usr/bin/ld: /usr/lib/libcrypto.dylib load command 7 unknown cmd field /usr/bin/ld: /usr/lib/libSystem.dylib load command 5 unknown cmd field make[1]: *** [openssl] Error 1 make: *** [sub_all] Error 1 I tried moving libssl.dylib, libcrypto.dylib and libSystem.dylib out of the /usr/bin directory, but the make function still wouldn't work. Any advice/suggestions is deeply appreciated. I searched the openssl-users mailing list and didn't find any further help beyond what I've done thus far. Quinn Moo Fusionist __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #342] Linking with libeay32.a and libssl32.a
I am compiling OpenSSL on Windows 2000. I read INSTALL.W32 that came with the source. I had a successful compile using Mingw32. Further down in INSTALL.W32 I see the following note... libcrypto.a and libssl.a are the static libraries. To use the DLLs, link with libeay32.a and libssl32.a instead. What does this mean in english? Don't I just put libeay32.dll and libssl32.dll in the windows system directory (C:\WINNT\system32)? Or is there more to it than that? Ron __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #328] DH_compute_key incompatable with PKCS #3
Can it be shown that this is a problem at a TLS level? I'd hate to make the proposed change just to discover that it breaks interoperability with other TLS clients and servers. Unless you can show that this incompatibility (which is very easy to deal with, BTW) creates an error, I can't really see that this should be changed. [[EMAIL PROTECTED] - Mon Nov 4 10:17:04 2002]: Hi, It seems that DH_compute_key is slightly incompatable with PKCS #3, if the derived secret z is too small. In particular, section 8.3 of PKCS #3 Integer-to-octet-string conversion, specifies that that output of the operation should be exactly k bytes long (where k is the number of bytes in the prime p). This seems to be regardless of how big the derived secret actually is (for example if z ends up being 5, and p is ~ 2^512, the output should still be 64 bytes long, with 63 of the leading bytes being 0). OpenSSL does not do it this way: it coverts the shared secret integer into a byte string of a length equivalent to the number of significant bytes in the shared integer. I initially noticed this while reading the dh manpage, and confirmed it by reading dh_key.c as included in openssl-0.9.6g I believe this can be fixed by memset'ing the key parameter to all 0s before doing any operations, then returning DH_size(dh) regardless of the size of the resulting integer. Regards, Jack -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #238] Solaris 2 shared libraries are built incorrectly with gcc
[[EMAIL PROTECTED] - Wed Aug 21 22:21:52 2002]: When configuring OpenSSL 0.9.6g for solaris-sparcv8-gcc/solaris-x86- gcc shared, the way the shared libcrypto.so and libssl.so are built is wrong: * gcc is invoked with gcc -G, but unfortunately this doesn't Please try the latest 0.9.6 snapshot, there's been changes that affect this behavior. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL Bug (More information)
I forgot to append this dump. I have tried to verify that the application does not send those 24 bytes by placing breakpoints on every call to SSL_write() 1 9 0.2855 (0.) CSV3.0(1) ChangeCipherSpec 1 10 0.2855 (0.) CSV3.0(64) Handshake Finished md5_hash[16]= 15 3b 46 16 dc d6 2d 50 36 b7 7e f4 c4 cd ab 57 sha_hash[20]= e8 17 13 cb 5b 89 be f8 ce a7 94 f8 73 03 81 ee 6e f8 15 cf 1 11 0.6284 (0.3428) SCV3.0(1) ChangeCipherSpec 1 12 0.7388 (0.1104) SCV3.0(64) Handshake Finished md5_hash[16]= 50 c0 35 e3 13 14 f3 1e 5b 14 c3 ef e7 f4 bc f5 sha_hash[20]= dd 07 2c 1d 18 6e 95 63 d4 ad f9 82 e7 f4 1c 5e 21 77 4a a8 1 13 0.7394 (0.0006) CSV3.0(24) application_data --- --- 1 14 0.7394 (0.) CSV3.0(168) application_data --- GET https://test.transunionnetaccess.com:3018/?PING HTTP/1.0 Connection: Keep-Alive User-Agent: Java SSL Client Connection: KeepAlive --- 1 0.8433 (0.1039) SC TCP FIN 1 0.8439 (0.0005) CS TCP FIN __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL Bug
I am using OpenSSL 0.9.6d. The application uses a Win32 compile, but this problem has been demonstrated under a FreeBSD compile too. I was doing application development (not the topic of this email) interacting with an IBM developed SSL library. I experienced unexpected disconnects immediately after the SSL handshake takes place. According to the IBM developer, this is an OpenSSL bug due to an extra 24 bytes supposedly sent by OpenSSL after the handshake is complete. I did some more digging over the weekend, and ran some more traces for IBM - what I found was that OpenSSL sends an additional packet of 24 bytes of what appears to be garbage following the handshake. The OpenSSL libraries and the s_client command both behave in this manor. The traces I gathered using ssldump demonstrate the working (Java) and non-working (OpenSSL) scenarios. In summary, this ends up being an OpenSSL issue. I guess for the time being it'll have to be noted that TUNA doesn't play ball with OpenSSL, at least until such time as someone on the client side can get rid of those 24 bytes. using the z/OS System SSL libraries. In the meantime, it is definately an OpenSSL bug, and that's about as far as we will take it. Can anyone shed some light on this supposed 24 extra bytes sent after the handshake? Below is a sample TCP dump showing the IBM server simply hanging up on the OpenSSL client. New TCP connection #1: 192.168.0.241(2549) - 63.78.183.70(3018) 1 1 0.1667 (0.1667) CS SSLv2 compatible client hello Version 3.1 cipher suites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL2_CK_3DES TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 SSL2_CK_IDEA SSL2_CK_RC2 SSL2_CK_RC4 SSL2_CK_RC464 TLS_DHE_DSS_WITH_RC2_56_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA SSL2_CK_DES TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5 SSL2_CK_RC2_EXPORT40 SSL2_CK_RC4_EXPORT40 1 2 0.2779 (0.) SC Handshake ServerHello Version 3.0 session_id[32]= 28 f9 ef a6 18 2c fb aa fc 34 2d 4e 3e 69 22 c8 ad 80 5a 4b b7 4c c9 53 4d db 56 76 36 fd 71 1e cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 1 3 0.2799 (0.0019) SC Handshake Certificate 1 4 0.3990 (0.1191) SC Handshake CertificateRequest certificate_types rsa_sign certificate_authority 30 81 81 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 13 08 49 6c 6c 69 6e 6f 69 73 31 10 30 0e 06 03 55 04 07 13 07 43 68 69 63 61 67 6f 31 18 30 16 06 03 55 04 0a 13 0f 54 72 61 6e 73 20 55 6e 69 6f 6e 20 4c 4c 43 31 10 30 0e 06 03 55 04 0b 13 07 53 79 73 74 65 6d 73 31 21 30 1f 06 03 55 04 03 13 18 54 72 61 6e 73 20 55 6e 69 6f 6e 20 43 49 43 53 20 52 6f 6f 74 20 43 41 certificate_authority 30 81 95 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 13 08 49 6c 6c 69 6e 6f 69 73 31 10 30 0e 06 03 55 04 07 13 07 43 68 69 63 61 67 6f 31 18 30 16 06 03 55 04 0a 13 0f 54 72 61 6e 73 20 55 6e 69 6f 6e 20 4c 4c 43 31 10 30 0e 06 03 55 04 0b 13 07 53 79 73 74 65 6d 73 31 10 30 0e 06 03 55 04 0c 13 07 53 79 73 74 65 6d 73 31 23 30 21 06 03 55 04 03 13 1a 54 72 61 6e 73 20 55 6e 69 6f 6e 20 43 49 43 53 20 53 69 67 6e 65 72 20 43 41 certificate_authority 30 81 81 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 13 08 49 6c 6c 69 6e 6f 69 73 31 10 30 0e 06 03 55 04 07 13 07 43 68 69 63 61 67 6f 31 18 30 16 06 03 55 04 0a 13 0f 54 72 61 6e 73 20 55 6e 69 6f 6e 20 4c 4c 43 31 0c 30 0a 06 03 55 04 0b 13 03 43 50 41 31 25 30 23 06 03 55 04 03 13 1c 74 65 73 74 2e 74 72 61 6e 73 75 6e 69 6f 6e 6e 65 74 61 63 63 65 73 73 2e 63 6f 6d certificate_authority 30 81 81 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 11 30 0f 06 03 55 04 08 13 08 49 6c 6c 69 6e 6f 69 73 31 10 30 0e 06 03 55 04 07 13 07 43 68 69 63 61 67 6f 31 18 30 16 06 03 55 04 0a 13 0f 54 72 61 6e 73 20 55 6e 69 6f 6e 20 4c 4c 43 31 0c 30 0a 06 03 55 04 0b 13 03 43 50 41 31 25 30 23 06 03 55 04
Re: [openssl.org #341] problems with make on jaguar mac os x10.2
In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 09:17:32 +0100 (MET), Quinn Moo via RT [EMAIL PROTECTED] said: rt After running a successful rt rt ./config --prefix=/usr --openssldir=/usr no-asm rt rt of openssl-0.9.6g, I tried to run the make. Here is the results: rt rt /usr/bin/ld: /usr/lib/libssl.dylib load command 8 unknown cmd field rt /usr/bin/ld: /usr/lib/libcrypto.dylib load command 7 unknown cmd field rt /usr/bin/ld: /usr/lib/libSystem.dylib load command 5 unknown cmd field rt make[1]: *** [openssl] Error 1 rt make: *** [sub_all] Error 1 rt rt I tried moving libssl.dylib, libcrypto.dylib and libSystem.dylib out of rt the /usr/bin directory, but the make function still wouldn't work. Any rt advice/suggestions is deeply appreciated. I searched the openssl-users rt mailing list and didn't find any further help beyond what I've done thus rt far. The same errors or different ones? -- 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 #325] Open SSL on Bug on Win32
In message [EMAIL PROTECTED] on Tue, 5 Nov 2002 08:57:10 +0100 (MET), Richard Levitte - VMS Whacker via RT [EMAIL PROTECTED] said: rt What about trying to do the following before running nmake: rt rt C:\Program Files\Microsoft Visual Studio .Net\VC7\bin\VCVARS32 rt rt If this doesn't work, look in C:\Program Files\Microsoft Visual Studio .Net\VC7\bin rt for any .BAT file that sets up an environment for you. You need that rt for CMD to be able to find the compiler (cl.exe). rt rt Please tell us if that solved it for you, and if the correct .BAT file rt was something else than VCVARS32.BAT, please tell us so we can mention rt that in our documentation. Any result? -- 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 #325] Open SSL on Bug on Win32
In message [EMAIL PROTECTED] on Tue, 5 Nov 2002 08:57:10 +0100 (MET), Richard Levitte - VMS Whacker via RT [EMAIL PROTECTED] said: rt What about trying to do the following before running nmake: rt rt C:\Program Files\Microsoft Visual Studio .Net\VC7\bin\VCVARS32 rt rt If this doesn't work, look in C:\Program Files\Microsoft Visual Studio .Net\VC7\bin rt for any .BAT file that sets up an environment for you. You need that rt for CMD to be able to find the compiler (cl.exe). rt rt Please tell us if that solved it for you, and if the correct .BAT file rt was something else than VCVARS32.BAT, please tell us so we can mention rt that in our documentation. Any result? -- 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 Bug
On Wed, Nov 13, 2002 at 04:14:54PM -0800, Jeremiah Gowdy wrote: I am using OpenSSL 0.9.6d. The application uses a Win32 compile, but this problem has been demonstrated under a FreeBSD compile too. I was doing application development (not the topic of this email) interacting with an IBM developed SSL library. I experienced unexpected disconnects immediately after the SSL handshake takes place. According to the IBM developer, this is an OpenSSL bug due to an extra 24 bytes supposedly sent by OpenSSL after the handshake is complete. You are probably experiencing an effect caused by the following change for 0.9.6d: *) Implement a countermeasure against a vulnerability recently found in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment before application data chunks to avoid the use of known IVs with data potentially chosen by the attacker. In order to work around this incompatibility, the following new option was introduced for 0.9.6e: *) New option SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS for disabling the SSL 3.0/TLS 1.0 CBC vulnerability countermeasure that was added in OpenSSL 0.9.6d. This option is automatically enabled, if SSL_OP_ALL is set, please see the SSL_CTX_set_options manual page. Please update your version of OpenSSL, as beyond this particular problem 0.9.6d is known to have security vulnerabilities!!! Best regards, Lutz PS. Whether this is considered to be a bug on OpenSSL's side, or whether OpenSSL is correct in sending an empty fragment and the peer's software is incorrect, is another topic. -- 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 #333] x509.pod
Lutz Jaenicke via RT wrote: [[EMAIL PROTECTED] - Fri Nov 8 12:19:04 2002]: Dear all, I identified that the Documentation in doc/apps/x509.pod is wrong if passed through pod2latex. The line =head1 NAME OPTIONS causes a wrong representation in the tex-File (and maybe in others too) I'm not a perl guru, I fixed it by surrounding =head1 BNAME OPTIONS Hmm, I just checked with pod2latex of perl 5.6.1 and cannot find any problems in the handling of =head1 ... Best regards, Lutz Hi Lutz, the problem is in fact not in the handling of =head1 instruction. It encounters after pod2latex -full -modify -out main.tex *.pod and is in the misinterpretation of the =head1 NAME string in the modify mode. Run in your doc/apps directory fgrep =head1 NAME *.pod you'll get CA.pl.pod:=head1 NAME asn1parse.pod:=head1 NAME ...more files spkac.pod:=head1 NAME verify.pod:=head1 NAME version.pod:=head1 NAME x509.pod:=head1 NAME x509.pod:=head1 NAME OPTIONS all but the last are fine here. How one can stop the pod2latex to misunderstand the =head1 NAME OPTIONS string? Regards, Ernst -- Ernst G Giessmann (ES22a) T-Systems GmbH ITC-Security Goslarer Ufer 35, D-10589 Berlin phone:+49-30-3497-4342 mailto:ErnstG.Giessmann;t-systems.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #333] x509.pod
In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 11:24:16
+0100 (MET), Ernst G Giessmann via RT [EMAIL PROTECTED] said:
rt Run in your doc/apps directory
rt
rt fgrep =head1 NAME *.pod
rt
rt you'll get
rt
rt CA.pl.pod:=head1 NAME
rt asn1parse.pod:=head1 NAME
rt ...more files
rt spkac.pod:=head1 NAME
rt verify.pod:=head1 NAME
rt version.pod:=head1 NAME
rt x509.pod:=head1 NAME
rt x509.pod:=head1 NAME OPTIONS
rt
rt all but the last are fine here. How one can stop the pod2latex to
rt misunderstand the =head1 NAME OPTIONS string?
Hmm, I can't see any way to stop pod2latex, except maybe changing the
following line in Pod::LaTeX:
if ($self-{_CURRENT_HEAD1} =~ /^NAME/i $self-ReplaceNAMEwithSection()) {
to:
if ($self-{_CURRENT_HEAD1} =~ /^NAME\s*$/i $self-ReplaceNAMEwithSection()) {
This might be a worthy bug report to the authors of the Pod system.
--
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 #333] x509.pod
In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 11:24:16
+0100 (MET), Ernst G Giessmann via RT [EMAIL PROTECTED] said:
rt Run in your doc/apps directory
rt
rt fgrep =head1 NAME *.pod
rt
rt you'll get
rt
rt CA.pl.pod:=head1 NAME
rt asn1parse.pod:=head1 NAME
rt ...more files
rt spkac.pod:=head1 NAME
rt verify.pod:=head1 NAME
rt version.pod:=head1 NAME
rt x509.pod:=head1 NAME
rt x509.pod:=head1 NAME OPTIONS
rt
rt all but the last are fine here. How one can stop the pod2latex to
rt misunderstand the =head1 NAME OPTIONS string?
Hmm, I can't see any way to stop pod2latex, except maybe changing the
following line in Pod::LaTeX:
if ($self-{_CURRENT_HEAD1} =~ /^NAME/i $self-ReplaceNAMEwithSection()) {
to:
if ($self-{_CURRENT_HEAD1} =~ /^NAME\s*$/i $self-ReplaceNAMEwithSection()) {
This might be a worthy bug report to the authors of the Pod system.
--
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]
[openssl.org #338] MSDOS/djgpp patches
I just applied the patch and committed. Please test tomorrows
snapshot.
This ticket is now resolved.
[[EMAIL PROTECTED] - Tue Nov 12 22:31:27 2002]:
Here are some patches for MSDOS and djgpp using Watt-32 tcp/ip
stack.
Patch against snapshot 11-Nov 2002.
1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due
to name-clash with Watt-32.
2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to
name-clash
with stdlib.h
3. Added calls to dbug_init()/sock_init() in some demo programs.
4. Changed cflags/lflags in configure. Watt-32 install root now
taken
from $WATT_ROOT.
---
diff -B -H -u3 -r ./apps/s_client.c ./patch/apps/s_client.c
--- ./apps/s_client.c Tue Jul 16 07:00:18 2002
+++ ./patch/apps/s_client.cTue Nov 12 18:06:32 2002
@@ -746,8 +746,8 @@
goto shut;
}
}
-#ifdef OPENSSL_SYS_WINDOWS
- /* Assume Windows can always write */
+#if defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_MSDOS)
+/* Assume Windows/DOS can always write */
else if (!ssl_pending write_tty)
#else
else if (!ssl_pending FD_ISSET(fileno(stdout),writefds))
diff -B -H -u3 -r ./apps/s_server.c ./patch/apps/s_server.c
--- ./apps/s_server.c Thu Aug 15 15:00:20 2002
+++ ./patch/apps/s_server.cTue Nov 12 18:02:08 2002
@@ -1473,8 +1473,8 @@
else
{
BIO_printf(bio_s_out,read R BLOCK\n);
-#ifndef OPENSSL_SYS_MSDOS
-sleep(1);
+#if !defined(OPENSSL_SYS_MSDOS) !defined(__DJGPP__)
+ sleep(1);
#endif
continue;
}
diff -B -H -u3 -r ./apps/s_socket.c ./patch/apps/s_socket.c
--- ./apps/s_socket.c Tue Feb 20 18:00:10 2001
+++ ./patch/apps/s_socket.cThu Sep 13 08:23:08 2002
@@ -85,7 +85,7 @@
#ifdef OPENSSL_SYS_WINDOWS
static void sock_cleanup(void);
#endif
-static int sock_init(void);
+static int ssl_sock_init(void);
static int init_client_ip(int *sock,unsigned char ip[4], int
port);
static int init_server(int *sock, int port);
static int init_server_long(int *sock, int port,char *ip);
@@ -146,9 +146,16 @@
}
#endif
-static int sock_init(void)
+static int ssl_sock_init(void)
{
-#ifdef OPENSSL_SYS_WINDOWS
+#ifdef WATT32
+extern int _watt_do_exit;
+_watt_do_exit = 0;
+dbug_init();
+if (sock_init())
+ return (0);
+
+#elif defined(OPENSSL_SYS_WINDOWS)
if (!wsa_init_done)
{
int err;
@@ -196,7 +203,7 @@
struct sockaddr_in them;
int s,i;
- if (!sock_init()) return(0);
+ if (!ssl_sock_init()) return(0);
memset((char *)them,0,sizeof(them));
them.sin_family=AF_INET;
@@ -261,7 +268,7 @@
struct sockaddr_in server;
int s= -1,i;
- if (!sock_init()) return(0);
+ if (!ssl_sock_init()) return(0);
memset((char *)server,0,sizeof(server));
server.sin_family=AF_INET;
@@ -318,7 +325,7 @@
int len;
/* struct linger ling; */
- if (!sock_init()) return(0);
+ if (!ssl_sock_init()) return(0);
#ifndef OPENSSL_SYS_WINDOWS
redoit:
@@ -448,7 +455,7 @@
{ /* do a gethostbyname */
struct hostent *he;
- if (!sock_init()) return(0);
+ if (!ssl_sock_init()) return(0);
he=GetHostByName(str);
if (he == NULL)
diff -B -H -u3 -r ./configur ./patch/configur
--- ./configur Tue Nov 12 17:56:10 2002
+++ ./patch/configur Tue Nov 12 18:00:44 2002
@@ -521,7 +521,7 @@
Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486
-Wall:::CYGWIN32::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
# DJGPP
-DJGPP,
gcc:-I/dev/env/DJDIR/watt32/inc -DTERMIOS -DL_ENDIAN
-fomit-frame-pointer -O2
-Wall:::MSDOS:-L/dev/env/DJDIR/watt32/lib
-lwatt:BN_L
LONG ${x86_gcc_des} ${x86_gcc_opts}::,
+DJGPP,
gcc:-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN
-fomit-frame-pointer -O2 -Wall:::MSDOS:-L/dev/env/WATT_ROOT/lib
-lwatt:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}::,
# Ultrix from Bernhard Simon [EMAIL PROTECTED]
ultrix-cc,cc:-std1 -O -Olimit 1000
-DL_ENDIAN::(unknown):::,
diff -B -H -u3 -r ./crypto/bio/b_sock.c ./patch/crypto/bio/b_sock.c
--- ./crypto/bio/b_sock.c Thu Jun 13 21:00:34 2002
+++ ./patch/crypto/bio/b_sock.cMon Jun 17 11:24:28 2002
@@ -463,7 +463,14 @@
}
}
#endif /* OPENSSL_SYS_WINDOWS */
- return(1);
+
+#ifdef WATT32
+extern int _watt_do_exit;
+_watt_do_exit = 0;/* don't make sock_init() call
exit()
*/
+if (sock_init())
+ return (-1);
+#endif
+return(1);
}
void BIO_sock_cleanup(void)
diff -B -H -u3 -r ./crypto/bio/bss_log.c
./patch/crypto/bio/bss_log.c
--- ./crypto/bio/bss_log.c Thu Feb 14 16:00:44 2002
+++ ./patch/crypto/bio/bss_log.c Tue Nov 12 18:04:32 2002
@@ -77,7 +77,7 @@
# include starlet.h
AW: [openssl.org #333] x509.pod
-Urspr üngliche Nachricht-
Von: Lutz Jaenicke via RT [SMTP:[EMAIL PROTECTED]]
Gesendet am: Donnerstag, 14. November 2002 12:15
An: Giessmann, Ernstg
Cc: [EMAIL PROTECTED]
Betreff: [openssl.org #333] x509.pod
[[EMAIL PROTECTED] - Thu Nov 14 11:47:20 2002]:
In message [EMAIL PROTECTED] on Thu, 14 Nov
2002 11:24:16 +0100 (MET), Ernst G Giessmann via RT [EMAIL PROTECTED]
said:
rt Run in your doc/apps directory
rt
rt fgrep =head1 NAME *.pod
rt
rt you'll get
rt
rt CA.pl.pod:=head1 NAME
rt asn1parse.pod:=head1 NAME
rt ...more files
rt spkac.pod:=head1 NAME
rt verify.pod:=head1 NAME
rt version.pod:=head1 NAME
rt x509.pod:=head1 NAME
rt x509.pod:=head1 NAME OPTIONS
rt
rt all but the last are fine here. How one can stop the pod2latex to
rt misunderstand the =head1 NAME OPTIONS string?
Hmm, I can't see any way to stop pod2latex, except maybe changing the
following line in Pod::LaTeX:
if ($self-{_CURRENT_HEAD1} =~ /^NAME/i $self-
ReplaceNAMEwithSection()) {
to:
if ($self-{_CURRENT_HEAD1} =~ /^NAME\s*$/i $self-
ReplaceNAMEwithSection()) {
This might be a worthy bug report to the authors of POD.
Probably this is a bug in the POD handling.
In any case I have chosen the opportunistic approach and changed the
name of the section :-)
Hi Lutz,
I guess that in this case
=head1 BNAME OPTIONS
is less opportunistic and therefore a bit better workaround saving the section
name for the next generation ;-)
Ernst
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: Please try these specific snapshots
On Thu, Nov 14, 2002 at 12:02:28AM +0100, Richard Levitte - VMS Whacker wrote:
openssl-0.9.6-stable-SNAP-200211xx.tar.gz non-engine version
[...]
openssl-0.9.7-stable-SNAP-200211xx.tar.gz
Hi,
a few problems.
The Configure script still uses the old deprecated -m486 instead of the
-march=i486 option:
0.9.6-stable-SNAP-20021112:
==
--- Configure.orig 2002-11-14 12:14:43.0 +0100
+++ Configure 2002-11-14 12:15:00.0 +0100
@@ -477,7 +477,7 @@ my %table=(
# Cygwin
Cygwin-pre1.3, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -m486
-Wall::(unknown)::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}::win32,
-Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -m486 -WallBN_LLONG
${x86_gcc_des} ${x86_gcc_opts}::win32:cygwin-shared:::.dll,
+Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -march=i486
+-WallBN_LLONG ${x86_gcc_des} ${x86_gcc_opts}::win32:cygwin-shared:::.dll,
# Ultrix from Bernhard Simon [EMAIL PROTECTED]
ultrix-cc,cc:-std1 -O -Olimit 1000 -DL_ENDIAN::(unknown)::,
==
0.9.7-stable-SNAP-20021112:
==
--- Configure.orig 2002-11-14 12:20:39.0 +0100
+++ Configure 2002-11-14 12:20:52.0 +0100
@@ -520,7 +520,7 @@ my %table=(
# Cygwin
Cygwin-pre1.3, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486
-Wall::(unknown):CYGWIN32::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}::win32,
-Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486
-Wall:::CYGWIN32::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
+Cygwin, gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
+-Wall:::CYGWIN32::BN_LLONG ${x86_gcc_des}
+${x86_gcc_opts}:${x86_out_asm}:win32:cygwin-shared:::.dll,
# DJGPP
DJGPP, gcc:-I/dev/env/DJDIR/watt32/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer
-O2 -Wall:::MSDOS:-L/dev/env/DJDIR/watt32/lib -lwatt:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}::,
==
The Cygwin build script in the util subdir suffers from a missing
`make depend':
Both openssl versions:
==
--- util/cygwin.sh.orig 2002-11-14 12:16:03.0 +0100
+++ util/cygwin.sh 2002-11-14 12:07:51.0 +0100
@@ -96,6 +96,8 @@ fi
get_openssl_version
+make depend || exit 1
+
make || exit 1
base_install
==
Other than that, the util/cygwin.sh file still has wrong permissions
which prevents building the official Cygwin version without having
to chmod +x the script first.
Even though `make depend' has been called, the following happens in the
0.9.6-stable-SNAP-20021112 build:
making all in test...
make[1]: Entering directory `/src/openssl-0.9.6-stable-SNAP-20021112/test'
gcc -I../include -DTHREADS -DDSO_WIN32 -DNO_IDEA -DNO_RC5 -DNO_MDC2 -DTERMIOS
-DL_ENDIAN -fomit-frame-pointer -O2 -march=i486 -Wall -c -o bntest.o bntest.c
gcc -o bntest -I../include -DTHREADS -DDSO_WIN32 -DNO_IDEA -DNO_RC5 -DNO_MDC2
-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -march=i486 -Wall bntest.o -L..
-lcrypto
make[1]: *** No rule to make target `ideatest.o', needed by `ideatest'. Stop.
make[1]: Leaving directory `/src/openssl-0.9.6-stable-SNAP-20021112/test'
make: *** [sub_all] Error 1
This doesn't happen in 0.9.7-stable-SNAP-20021112.
Sorry, I have no patch for this one.
Corinna
--
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen;redhat.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: Please try these specific snapshots
In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 12:53:03 +0100, Corinna Vinschen [EMAIL PROTECTED] said: vinschen The Configure script still uses the old deprecated -m486 instead of the vinschen -march=i486 option: Patch applied. vinschen The Cygwin build script in the util subdir suffers from a missing vinschen `make depend': Patch applied. vinschen Other than that, the util/cygwin.sh file still has wrong permissions vinschen which prevents building the official Cygwin version without having vinschen to chmod +x the script first. Fixed. vinschen Even though `make depend' has been called, the following happens in the vinschen 0.9.6-stable-SNAP-20021112 build: vinschen vinschen making all in test... vinschen make[1]: Entering directory `/src/openssl-0.9.6-stable-SNAP-20021112/test' vinschen gcc -I../include -DTHREADS -DDSO_WIN32 -DNO_IDEA -DNO_RC5 -DNO_MDC2 -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -march=i486 -Wall -c -o bntest.o bntest.c vinschen gcc -o bntest -I../include -DTHREADS -DDSO_WIN32 -DNO_IDEA -DNO_RC5 -DNO_MDC2 -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -march=i486 -Wall bntest.o -L.. -lcrypto vinschen make[1]: *** No rule to make target `ideatest.o', needed by `ideatest'. Stop. vinschen make[1]: Leaving directory `/src/openssl-0.9.6-stable-SNAP-20021112/test' vinschen make: *** [sub_all] Error 1 vinschen vinschen This doesn't happen in 0.9.7-stable-SNAP-20021112. vinschen Sorry, I have no patch for this one. OK, I'll just copy the mechanism from 0.9.7-stable... I'll commit the result soon, please test tomorrows snapshots. -- 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]
[openssl.org #292] FAQ: How can I check authenticity of a tarball?
Good idea. Done.
This ticket is now resolved.
[[EMAIL PROTECTED] - Fri Sep 27 11:17:57 2002]:
I write to ask if you can kindly supply such a FAQ
E.g.
We provide MD5 digests and ASC signatures of each tarball.
Use MD5 to check that a tarball from a mirror site is identical,
e.g.
md5sum TARBALL | awk '{print $1;}' | cmp - TARBALL.md5
You can check authenticity using pgp or gpg. You need
the OpenSSL team public key used to sign it: download it
from ??. Then just do
pgp TARBALL.asc
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
Richard, Thank you for your response. sjm Message History From: Richard Levitte via RT [EMAIL PROTECTED]@serv01.aet.tu-cottbus.de on 11/14/2002 12:54 AM CET Please respond to [EMAIL PROTECTED] DELEGATED - Sent by:@serv01.aet.tu-cottbus.de To:[EMAIL PROTECTED]; Steven J Mones/NewYork/DBNA/DeuBa@DBNA cc:[EMAIL PROTECTED] Subject:[openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390 Hi, [[EMAIL PROTECTED] - Thu Oct 10 20:39:27 2002]: 2. Failure! Has to do with selftest.pl looking for a last line in maketest.log for platform name. May be related to other issues shown below. 3. make: Makefile.ssl: line 238: Warning -- FSUM9433 Duplicate entry [../include/openssl/e_os.h] in prerequisite list We are concerned about this. Just a warning, meaning there is (was?) a double dependency on e_os.h. I believe that can safely be ignored... Which Makefile.ssl, BTW? 4. 2006 file=./engine_list.c, line=399, number=72, address=1C1E67C8 72 bytes leaked in 1 chunks We are concerned about this. That was recently fixed, please try the latest 0.9.6 snapshot. -- Richard Levitte -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #29] -Wl,-Bsymbolic in 0.9.6d broke shared builds
[[EMAIL PROTECTED] - Sun May 12 22:48:56 2002]: JFYI, when updating our package from 0.9.6c to 0.9.6d I've noticed that the new shared libcrypto library doesn't work anymore. The openssl(1) binary wouldn't recognize any of the block ciphers. I tracked this down to the addition of -Wl,-Bsymbolic. Removing that option solved the problem for us. Hmm, if you, instead of removing that option, build and check the resulting library with 'nm', what exactly do you get? It's a mystery to me why things should go wrong for you. Also 0.9.6d would tend to recompile some previously built files during the make install stage, resulting in static linking of openssl(1) (which is undesired in our case). The very simple reason is that there are aspects of the shared library support that we haven't inserted in the 0.9.6 tree. Therefore, the openssl application gets linked with the static library, to be on the safe side. 0.9.7 is a different story. About the -Wl,-Bsymbolic problem, have you tried downloading a recent 0.9.6 snapshot and checked that the problem is still present? -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #115] aix 5.1 openssl compiling problem and solution
I've reduced -O3 to -O1. This ticket is now resolved. [[EMAIL PROTECTED] - Sun Jun 23 16:44:16 2002]: hi, i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX 5.1 (ML 510002) in a 64Bit environment with gcc-2.9AIX51.xx. when i run 'make test' the following errors appear: Generate a set of DSA parameters ./dsatest test generation of DSA parameters .++* ...++..+...++.+..+..+++* seed D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3 counter=105 h=2 P: 00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68: 69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d: 78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac: 32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36: ee:31:c8:02:91 Q: 00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30: f4:8e:da:ce:91:5f G: 62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5: 00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce: 2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21: 92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53: e6:d7:88:02 540910:error:0A071003:dsa routines:DSA_do_verify:BN lib:dsa_ossl.c:305: make[1]: *** [test_dsa] Error 1 make[1]: Leaving directory `/usr/opt/distrib/src/openssl-0.9.6d/test' make: *** [tests] Error 2 After a little talk with Lutz Jaenicke, i playing around with optimizing setting in the Makefile. CFLAG= -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DAIX -DB_ENDIAN I changed the -O3 setting to -O1 and the testsuite runs without errors. Next, i compile openssh-3.2.3 - no problems. best regards thomas -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #136] [Fwd: Bug#151197: openssl: verify should fail when verification fails]
I would also suggest this not get changed in the 0.9.6 branch. I'm even dubious about changing it in the 0.9.7 branch. The reason is that such a change breaks the current test scripts, and then I can only guess what other people's scripts will do. The current solution is instead to parse the output from openssl verify. I'll change the milestone on this ticket to 0.9.8. [steve - Fri Aug 30 20:40:29 2002]: I agree that this should be done but there are quite a few cases to cover. The exit code could be modified to represent the actual verify error. This is possible because code 1 is used for other errors and is not a valid verify failure reason. However theres also the issue of what should happen if multiple certificates are verified: should it check all the certificates (as it currently does) and have the exit code represent the first error or halt on the first error with a failure code? I'd suggest this behaviour is made controllable via some new command line options. Steve. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #162] SSL_shutdown return 0 in case of SSLv3_client_method
Lütz, did you get anywhere with this? [jaenicke - Tue Jul 23 15:13:25 2002]: [[EMAIL PROTECTED] - Tue Jul 23 15:07:51 2002]: The problem is that SSL_shutdown() returns 0 with SSL_get_error() == SSL_ERROR_SYSCALL in both cases. The first 0 is ok. The second 0 is not ok, it may indicate, that the peer closed the connection but did not send back the close message. This won't hurt you much and could probably be ignored. In any case I'll have to go through the code again and maybe update the manual page to be more clear about what might happen. Therefore I have bounced your message into the request tracker. PS: If I'm using SSLv2_client_method instead of SSLv3_client_method, the first SSL_shutdown() returns 1 (no problems) SSLv2 does not specify correct shutdown behaviour, so it cannot fail :-) Best regards, Lutz -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #343] Fw: When scrubbing secrets in memory doesn't work
Hi, I recently received this email from the Bugtraq mailing list, and was wondering if it was relevant to OpenSSL. I checked the README and INSTALL files from version 0.9.6g and there doesn't appear to be anything relevant. Regards, Adrian - Original Message - From: Michael Wojcik [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 12, 2002 4:07 PM Subject: RE: When scrubbing secrets in memory doesn't work Reposted. -Original Message- From: Michael Wojcik Sent: Wednesday, November 06, 2002 12:25 AM To: 'Michael Howard' Cc: [EMAIL PROTECTED] Subject: RE: When scrubbing secrets in memory doesn't work From: Michael Howard [mailto:mikehow;microsoft.com] Sent: Tuesday, November 05, 2002 5:13 PM [memset doesn't always] I don't know if you followed the discussion on Vuln-dev after Peter Gutmann mentioned your article, 30-31 October, but Dom De Vitto[1] and I both described ways of avoiding this problem that work on any conforming C90/94/99 implementation[2]. Pavel Kankovsky[3] and I both noted that De Vitto's simple suggestion of using the volatile sc-specifier should sufficient for any conforming C implementation, at least as we read the standards (and with the caveat that passing a volatile-qualified pointer to memset may not be valid, so assignment might have to be done manually), though I prefer the external memset approach for various reasons[4]. Dan Kaminsky makes the general point that introducing dependencies that can only be evaluated at run time also does the trick[5], though that's generally more work than the simple volatile and external memset solutions. In sum, this is not a particularly interesting problem. It's useful to have it pointed out (and we might have hoped that the authors of security-sensitive software would be more familiar with optimization techniques, the language standards, and what might happen to this kind of application of memset), and the maintainers of code that handles passwords should check for and correct it, but contra Peter Gutmann it does not appear to be a hard problem to solve, nor need solutions be necessarily implementation-specific. Of the solutions given in your article, all should work on your implementation, but the first: memset(ptr, 0, len); (volatile char *)ptr[0] = (volatile char *)ptr[1]; is clearly preferable as it is portable. (I think - that lvalue cast may not be legal, actually. Or, for that matter, casting on volatility. I'd have to check.) It's worth noting that I believe the standard *still* allows a conforming implementation to skip the memset in the case of your first solution, too. Because the pointer being passed to memset is not itself volatile-qualified, the implementation can apply the as if rule - the generated code need only behave *as if* following the rules of the abstract machine, provided all side effects visible to the program are maintained. (That's a gloss, not language taken directly from the standard, but it's the basic idea.) A clever optimiser could note that it is only necessary that it perform the volatile read and write in the second line. So that's not a portable solution either, actually. My advice: use an external memset wrapper. Simple, safe, portable. 1. http://makeashorterlink.com/?A5C922B52 2. http://makeashorterlink.com/?E50A12B52 3. http://makeashorterlink.com/?J11A62B52 4. http://makeashorterlink.com/?H32A23B52 5. http://makeashorterlink.com/?T1A924B52 Michael Wojcik Principal Software Systems Developer, Micro Focus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #162] SSL_shutdown return 0 in case of SSLv3_client_method
[levitte - Thu Nov 14 15:31:34 2002]: Lütz, did you get anywhere with this? No. I didn't have the time to look into it. And I don't know, whether I will find the time before next week. Maybe some hours are available on Saturday and/or Sunday... Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #186] [PATCH] Makefile.org GNU ld detection
I can't recall having gotten a response. However, since this has been tested by a bunch of others, I'll resolve this ticket. [levitte - Fri Oct 11 00:01:54 2002]: The question was, in what way does your patch make things better? Since there was no answer for quite a while, I assumed the question wouldn't be answered, and decided to resolve the ticket. Wrongly, it now seems, so I'll reopen it and let you answer the question. [levitte - Thu Oct 10 23:42:36 2002]: [[EMAIL PROTECTED] - Thu Oct 10 23:29:14 2002]: a question which was never CC'd to me. Also I'm not sure what is the meaning of these two entries: Tue Aug 13 17:52:03 2002 jaenicke - Milestone 0.9.6h added Tue Aug 13 17:52:13 2002 jaenicke - Subsystem Build added Oh, they're just keywords (kind of attributes) that were added to the entry. We use that to classify the reports we get. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Fixes for some Windows build failures
These are based on the 1113 snapshot. The first two are warnings, but the compiler options being used treat warnings as errors. crypto/aes/aes_cbc.c at lines 84 and 106 need a typecast to avoid signed/unsigned mismatch warning: for(n=0; n len; ++n) becomes: for(n=0; n (int)len; ++n) apps\ca.c line 1339 needs a typecast: if(strlen(outdir) = (j ? BSIZE-j*2-6 : BSIZE-8)) becomes: if((int)strlen(outdir) = (j ? BSIZE-j*2-6 : BSIZE-8)) crytpto/buffer/buffer.h needs to include stddef.h for size_t __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Fixes for some Windows build failures
In message [EMAIL PROTECTED] on Fri, 15 Nov 2002 02:28:11 +1100, Steven Reddie [EMAIL PROTECTED] said: OK, I've committed fixes. Please try again tomorrow (the 1114 snapshot will be ready then). smr These are based on the 1113 snapshot. The first two are warnings, but the smr compiler options being used treat warnings as errors. smr smr crypto/aes/aes_cbc.c at lines 84 and 106 need a typecast to avoid smr signed/unsigned mismatch warning: smrfor(n=0; n len; ++n) smr becomes: smrfor(n=0; n (int)len; ++n) smr smr apps\ca.c line 1339 needs a typecast: smrif(strlen(outdir) = (j ? BSIZE-j*2-6 : BSIZE-8)) smr becomes: smrif((int)strlen(outdir) = (j ? BSIZE-j*2-6 : BSIZE-8)) smr smr crytpto/buffer/buffer.h needs to include stddef.h for size_t -- 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: Fixes for some Windows build failures
Yes, that's better. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Richard Levitte - VMS Whacker Sent: Friday, 15 November 2002 2:55 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Fixes for some Windows build failures In message [EMAIL PROTECTED] on Fri, 15 Nov 2002 02:28:11 +1100, Steven Reddie [EMAIL PROTECTED] said: smr These are based on the 1113 snapshot. The first two are warnings, but the smr compiler options being used treat warnings as errors. smr smr crypto/aes/aes_cbc.c at lines 84 and 106 need a typecast to avoid smr signed/unsigned mismatch warning: smrfor(n=0; n len; ++n) smr becomes: smrfor(n=0; n (int)len; ++n) Does it work if we change: int n; to: unsigned long n; ? -- 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #192] tandem OSS configuration
Patch applied, thanks. Please test tomorrow's snapshots.
This ticket is now resolved.
[[EMAIL PROTECTED] - Fri Aug 2 10:52:26 2002]:
Hi,
Here's a patch that will provide compilation options on Tandem OSS
Non-Stop
Kernel.
The patches are made on config and Configure so a simple ./config
will
do
for Tandem users.
The patch was applied on openssl-0.9.6e.
Regards,
Robert van Hulsteijn
*** ./config.old Fri Mar 15 17:47:23 2002
--- ./config Fri Aug 1 13:01:56 2002
***
*** 317,322
--- 317,326
*CRAY*)
echo j90-cray-unicos; exit 0;
;;
+
+ NONSTOP_KERNEL*)
+echo nsr-tandem-nsk; exit 0;
+;;
esac
#
***
*** 600,605
--- 604,610
*-*-cygwin) OUT=Cygwin ;;
t3e-cray-unicosmk) OUT=cray-t3e ;;
j90-cray-unicos) OUT=cray-j90 ;;
+ nsr-tandem-nsk) OUT=tandem-c89 ;;
*) OUT=`echo $GUESSOS | awk -F- '{print $3}'`;;
esac
*** ./Configure.ori Fri May 10 01:05:49 2002
--- ./Configure Thu Aug 1 13:57:27 2002
***
*** 496,501
--- 496,504
# VxWorks for various targets
vxworks-ppc405,ccppc:-g -msoft-float -mlongcall -DVXWORKS
-DCPU=PPC405
-I\$(WIND_BASE)/target/h:::-r:,
+ # Compaq Non-Stop Kernel (Tandem)
+ tandem-c89,c89:-Ww -D__TANDEM -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED=1 -D_TANDEM_SOURCE
-DB_ENDIAN::(unknown)::THIRTY_TWO_BIT:::,
+
);
my @WinTargets=qw(VC-NT VC-WIN32 VC-WIN16 VC-W31-16 VC-W31-32 VC-
MSDOS
BC-32
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the
contents
herein and notify the sender immediately by return e-mail.
__
OpenSSL Project
http://www.openssl.org
Development Mailing List
[EMAIL PROTECTED]
Automated List Manager
[EMAIL PROTECTED]
--
Richard Levitte
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #220] bug in config (openssl-0.9.6g, Solaris2.6)
This ticket is now resolved. [levitte - Fri Oct 11 10:18:21 2002]: This ticket appears to be resolvable, but to be safe, I'll ask: is this still an issue? [guest - Fri Aug 16 11:04:41 2002]: Note that the solaris-sparcv9-cc and solaris-sparcv9-gcc configurations actually use just sparcv8plus code (32 bit); see Configure. I did not know that, since I looked at config only, but not at Configure. But still: is it assured that every sun4u machine has the sparcv8plus instruction set? If not, then the patch is still required as the isalist manpage says: Programs compiled for instruction sets that do not appear in the list will most likely experience perfomance degradation or not run at all on this machine. Only the solari64-sparcv9-... configuration really needs sparcv9. This is on a sun4u machine with 32-bit OS only: $ isalist sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc solaris-sparcv9-cc or ...-gcc are the configurations that should be used on this machine. Do you have a sun4u machine on which the solaris-sparcv9-cc/gcc code actually fails? I compiled OpenSSL straightaway for sparv8 since I was scared by the isalist manpage (s. above). I agree. Please try the attached patch The patch should not be necessary (and should probably be reverted in the CVS). -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
CVSWeb broken?
The CVSWeb link at the top of http://www.openssl.org/source/ is broken. How can I browse the source?
[openssl.org #239] Solaris 2/Intel shared libssl/libcrypto contain text relocations
Do you have the possibility to help out with this? The help needed would be to tell us exactly what assembler lines are incorrect, so we can hack the Perl code appropriately, or perhaps direct help with said Perl code. A quick solution is to configure with no-asm... [[EMAIL PROTECTED] - Wed Aug 21 22:22:09 2002]: Trying to build OpenSSL 0.9.6g on Solaris 8/Intel with a fixed solaris-x86-gcc shared configuration and a proper invokation of gcc (using -shared instead of gcc -G as explained in a previous report) fails since the assembler sources used contain text relocations. The link step fails with errors like this: + gcc -shared -G -o libcrypto.so.0.9.6 -h libcrypto.so.0 -z allextract libcrypto.a -L. -z defs -lsocket -lnsl -ldl -lc Text relocation remains referenced against symboloffset in file unknown 0x22d2 libcrypto.a(dx86-sol.o) and many more. This lets building libcrypto.so fail. Unfortunately, it is not even possible to turn off the -z text implied with -shared with a subsequent -z textoff, since the linker complains: ld: fatal: option -ztextoff and -ztext are incompatible ld: fatal: Flags processing errors Anyway, shared libraries with remaining text relocations are not really useful since they are not sharable, greatly diminishing their utility. So perlasm and the various x86 assembler implementations should be fixed to produce proper PIC code if shared libraries are to be produced. The affected files during the Solaris 8/Intel compilation were crypto/bf/asm/bx86-sol.o crypto/cast/asm/cx86-sol.o crypto/des/asm/dx86-sol.o crypto/des/asm/yx86-sol.o crypto/md5/asm/mx86-sol.o crypto/rc4/asm/rx86-sol.o crypto/sha/asm/sx86-sol.o For the record, here's the test report: OpenSSL self-test report: OpenSSL version: 0.9.6g Last change: [In 0.9.6g-engine release:]... Options: --prefix=/vol/openssl --openssldir=/vol/openssl/share shared OS (uname): SunOS arenal 5.8 Generic_111920-01 i86pc i386 OS (config): i86pc-whatever-solaris2 Target (default): solaris-x86-cc Target: solaris-x86-gcc Compiler: Configured with: /vol/gnu/src/gcc/gcc-3.1-branch- dist/configur e --prefix=/vol/gnu --with-local-prefix=/vol/gnu --disable-nls Thread model: posix gcc version 3.1 Test passed. Rainer -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
On Thu, 14 Nov 2002, Richard Levitte via RT wrote: Can it be shown that this is a problem at a TLS level? I'd hate to make the proposed change just to discover that it breaks interoperability with other TLS clients and servers. RFC 2246 is very vague: 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. [looks like this was copied directly from Netscape's SSLv3 docs] What conventional is supposed to mean in this case is totally unclear to me. If I read this with no other knowledge, I would probably assume conventional == compatible with PKCS #3, since that was the DH standard of choice around the time SSLv3 came out, and since Netscape probably used B-SAFE for the initial SSL implementations. OTOH, who knows? Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone should contact the TLS WG and ask for a clarification on this issue? [I'll do it if nobody else is interested] -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. -- 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 #328] DH_compute_key incompatable with PKCS #3
In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. -- 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]
[openssl.org #250] 'openssl ca' broken
When is once? I just checked, and ca.c has not changed in any way that would give that kind of message since 0.9.6... Could it be something wrong with index.txt? [[EMAIL PROTECTED] - Mon Aug 26 10:31:09 2002]: OpenSSL self-test report: OpenSSL version: 0.9.6g Last change: [In 0.9.6g-engine release:]... Options: no-idea --prefix=/usr/local --openssldir=/usr/local/ssl no-threads shared OS (uname): Linux binky 2.4.19 #1 Fri Aug 9 10:17:44 CEST 2002 i586 unknown OS (config): i586-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: gcc version 2.95.3 20010315 (release) Hi all, 'openssl ca -gencrl' worked once. Now I wanted to generate an updated CRL and got: Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase: 17764:error:0D065085:asn1 encoding routines:a2i_ASN1_INTEGER:short line:f_int.c:210: Regards Olaf -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #258] ssl3_output_cert_chain
Bodo, if you haven't had more correspondence on this ticket, you probably should resolve it... [bodo - Thu Aug 29 13:08:00 2002]: Can you elaborate what you think is buggy? 'make test' still succeeds if you substitute 10 for SSL3_RT_MAX_PLAIN_LENGTH in ssl3_write_bytes (ssl/s3_pkt.c), which sort of simulates very long certificate chains. There is a limit to certificate chains (SSL_MAX_CERT_LIST_DEFAULT by default, applications can change it). -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #136] [Fwd: Bug#151197: openssl: verify should fail when verification fails]
[levitte - Thu Nov 14 15:13:32 2002]: I would also suggest this not get changed in the 0.9.6 branch. I'm even dubious about changing it in the 0.9.7 branch. The reason is that such a change breaks the current test scripts, and then I can only guess what other people's scripts will do. The current solution is instead to parse the output from openssl verify. I'll change the milestone on this ticket to 0.9.8. Depends on how we do it. If we added a new command line option which would make the exit code reflect the verify status and which would keep the current behaviour if it wasn't present this need not break anything. However I agree that this new functionality and should be 0.9.8 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
I don't recall what happened to the other email thread, but I also submitted patches for that issue as well. The idea is to keep the OpenSSL internal data structures in ASCII. So I patched a couple of the conf routines to translate EBCDIC (read from a config file) into ASCII, etc. You need to do this anyway, because the ca program was double-translating some of the certificate fields on display, turning them into garbage. (I alluded to that in this msg thread, in fact.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support -Original Message- From: [EMAIL PROTECTED] [mailto:owner-openssl-dev;openssl.org]On Behalf Of Richard Levitte via RT Sent: Thursday, November 14, 2002 10:00 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390 [[EMAIL PROTECTED] - Thu Aug 29 09:12:28 2002]: Ok, so after getting past the previous problems, the testca script failed. Fixing this last problem allows the tests to successfully run to completion. The problem was that the ca app didn't like the result it got from ASN1_PRINTABLE_type() (apps/ca.c, line 1586) because the ASN1_PRINTABLE_type function had been modified to expect EBCDIC strings, and the string being tested is in ASCII. Since passing EBCDIC strings to a function named ASN1_PRINTABLE_type doesn't make a lot of sense to me, I chose to remove the EBCDIC part from crypto/asn1/a_print.c: It does make sense. If you look up the other reference to it in apps/ca.c, you'll see that it gets called with data coming from the configuration file. The configuration might be coded in EBCDIC. Changing this might become a larger can of worms than I think I'm willing to put in right now. We really need to design a better way to handle this, so we are absolutely certain we know what we have at all times. Right now, I can't say I'm sure what's what... -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
On Thu, 14 Nov 2002, Richard Levitte via RT wrote: Can it be shown that this is a problem at a TLS level? I'd hate to make the proposed change just to discover that it breaks interoperability with other TLS clients and servers. RFC 2246 is very vague: 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. [looks like this was copied directly from Netscape's SSLv3 docs] What conventional is supposed to mean in this case is totally unclear to me. If I read this with no other knowledge, I would probably assume conventional == compatible with PKCS #3, since that was the DH standard of choice around the time SSLv3 came out, and since Netscape probably used B-SAFE for the initial SSL implementations. OTOH, who knows? Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone should contact the TLS WG and ask for a clarification on this issue? [I'll do it if nobody else is interested] -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #261] [PATCHes] OpenSSL 0.9.6g: OBJ_txt2obj, EVP reinitialisation
The OBJ_txt2obj() problem has already been solved. The EVP reinit problem is very easy to solve, actually. Somply remove the flag variable, which is exactly what has been decided within the team. I'm sure many will scream at this decision. However, think about it, the only way that flag variable is useful is to take care of people who can't keep track of what they've done already (have we already called OpenSSL_add_all_ciphers() or not?). Also, if someone is imagining that several threads could do some kind of reinitialization of the in-memory cipher and digest database, think again. That would be a really good way to screw things up. The only time OpenSSL_add_all_ciphers(), OpenSSL_add_all_digests() and EVP_cleanup() should be used is when the running program has only one thread. And if a single-threaded program reinits by calling EVP_cleanup() and then OpenSSL_add_all_*(), it works a lot better if the flag variable isn't hindering. Again, that requires that the programmer keeps track of what he or she is doing. The change is now committed, and this ticket is now resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #237] [PATCH] Support for Subject Directory Attributes
[[EMAIL PROTECTED] - Thu Sep 5 09:23:59 2002]: This patch is a replacement for RT/openssl.org: Ticket #237. Please retract Ticket #237. The following patch provides basic support for Subject Directory Attributes, which are defined in the x509 spec (RFC 2459), but are currently unsupported by OpenSSL. openssl.cnf entries for Subject Directory Attributes should be formed as follows: subjectDirectoryAttribute = type:type-objectname, \ value:value-objectname|DER:hexstring Example: subjectDirectoryAttributes = type:corestreet,value:DER:3081cd3081ca3081ca... An OID for Corestreet Credential Validation has also been added to provide support for Dr. Silvio Micali's certificate validation mechanism. The follow diff is relative to the 9/03/02 snapshot. The new ASN1 generator in OpenSSL 0.9.8 should be able to do this using a human readable syntax. See ASN1_generate_nconf(3) and doc/openssl.txt in 0.9.8 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Patch for Win2000 Smartcardlogin
On Wed, Oct 02, 2002, Michael Bell wrote: Dr. Stephen Henson wrote: I've got some prototype code that allows arbitrary structures to be added to extensions, from the config file. It should allow the Win2000 smartcardlogin extensions to be added and just about anything else. Where can I find this code to test it? An early version of the code in now in 0.9.8-dev. Check out the docs in ASN1_generate_nconf(3) and doc/openssl.txt . 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 #264] [Patch] for Windows OpenSSL 0.9.6g (or earlier)
Thanks. The patch is applied and committed. This ticket is now resolved. [[EMAIL PROTECTED] - Sun Sep 1 19:15:59 2002]: I have found that OpenSSL version 0.9.6g (or earlier) on Windows can cause a problem that will prevent Window's Disk Administrator from being able to delete a logical drive from a system that has several logical drives associated with a physical drive. By using a tool call Filemon.exe (from http://www.sysinternals.com/sitemap.shtml) I was able to isolate the problem to be one in which a registry handle is not closed I was able to trace this occurance to a line in RAND_WIN.C. I then added a one line 'fix' after the query which closes the key and fixes the problem. In more detail, using symbolic debugging inside of OpenSSL, I found that during the first call to SSL_accept() OpenSSL ends up querying the HKEY_PERFORMANCE_DATA Registry key in order to get some random data. It turns out that this is one of those Windows oddities whereby you do not need to explicitly open this key, but you have to explicity close it or it leaves a handle open that results in this Disk Administrator problem. --- Pete Bobco --- -- [Patch for RAND_WIN.C] diff -ur \openssl-0.9.6g-orig/crypto/rand/rand_win.c \openssl-0.9.6g-work/crypto/rand/rand_win.c --- \openssl-0.9.6g-orig/crypto/rand/rand_win.c Thu Feb 21 05:56 :50 2002 +++ \openssl-0.9.6g-work/crypto/rand/rand_win.c Fri Aug 23 10:48 :20 2002 @@ -286,6 +286,15 @@ */ RAND_add(length, sizeof(length), 0); RAND_add(buf, length, length / 4.0); + + /* Close the Registry Key to allow Windows to cleanup/close the open handle + * Note: The 'HKEY_PERFORMANCE_DATA' key is implicitly opened when the + * RegQueryValueEx above is done. However, if it is not explicitly + * closed, it can cause disk partition manipulation problems. + */ + + RegCloseKey(HKEY_PERFORMANCE_DATA); + } if (buf) free(buf); __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #271] [PORT] A/UX 3
Applied to the 0.9.6 branch. This ticket is now resolved. [[EMAIL PROTECTED] - Fri Sep 6 09:43:56 2002]: Just a quick update... I should have submitted this *long* ago. The below patch allows for OpenSSL under A/UX. --- Configure.origThu Aug 22 15:10:28 2002 +++ Configure Thu Sep 5 16:17:03 2002 @@ -495,6 +495,9 @@ rhapsody-ppc-cc,cc:-O3 -DB_ENDIAN::(unknown)::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR:::, darwin-ppc-cc,cc:-O3 -D_DARWIN -DB_ENDIAN -fno-common::-D_REENTRANT::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR:::darwin-shared:- fPIC::.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib, +# A/UX +aux3-gcc,gcc:-O2 -DTERMIO::(unknown):-lbsd:RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR:::, + # Sony NEWS-OS 4.x newsos4-gcc,gcc:-O -DB_ENDIAN -DNEWS4::(unknown):-lmld -liberty:BN_LLONG RC4_CHAR RC4_CHUNK DES_PTR DES_RISC1 DES_UNROLL BF_PTR, -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #288] session reuse: getting old session cipher not returned errors
This ticket looks resolved, so I'll mark it as such. [[EMAIL PROTECTED] - Wed Sep 18 16:07:15 2002]: On Wed, Sep 18, 2002 at 04:03:26PM +0200, Steve Haslam via RT wrote: On Wed, Sep 18, 2002 at 09:18:22AM +0200, Lutz Jaenicke via RT wrote: Workaround: the problem is does not appear, when SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG is enabled, which is part of SSL_OP_ALL (see man SSL_CTX_set_options). As most applications enable SSL_OP_ALL, the problem was not discovered until now, even though it must be pretty old. Is enabling SSL_OP_ALL a good idea? I must admit, I hadn't noticed it in any code I was cribbing from. Duh, the manpage says it is safe and recommended. Kill me now. SRH -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #241] MacOS compilation bugs in OpenSSL 0.9.6g
The only conclusion I can make is that something went wrong during transfer or unpacking of the OpenSSL distribution. A freshly downloaded copy looks fine to me; I agree that something must have gone wrong with the unpacking at my end. thanks, --Lisa __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #241] MacOS compilation bugs in OpenSSL 0.9.6g
Thanks. This ticket is now resolved. [[EMAIL PROTECTED] - Fri Nov 15 01:13:20 2002]: The only conclusion I can make is that something went wrong during transfer or unpacking of the OpenSSL distribution. A freshly downloaded copy looks fine to me; I agree that something must have gone wrong with the unpacking at my end. thanks, --Lisa -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: IMPORTANT: Please try these specific snapshots
Test of snapshots for 13 November 2002 Tests that were performed: - configuration and build - test suite - installation (be wise and do it in some temporary directory) Optional things would be to test the following: - build and run mod_ssl with the new installation Using mod_ssl 2.8.12 and Apache 1.3.27, with mm-1.2.1 (I am not testing OpenSSH or shared libraries. I am testing engine support for CryptoSwift, in conjunction with Apache.) On Solaris 7, using SUNWspro C compiler (Workshop C 5.0) (sun4u-whatever-solaris2), 32 bit (Path includes SUNWspro bin directory, /usr/ccs/bin, and /usr/openwin/bin, where makedepend is found.) OpenSSL 0.9.7 snapshot openssl-SNAP-20021113: config - pass make depend - pass make - FAILED ../../include/openssl/aes.h, line 56: #error: AES is disabled. cc: acomp failed for aes-core.c *** Error code 2 make: Fatal error: Command failed for target aes_core.o openssl-e-0.9.6-stable-SNAP-20021113: config: pass, configured for solaris-sparcv9-cc make: pass make test: pass (with the exception of bc, which cleanly fails for lack of the right version of bc on this system) speed test: accesses cswift engine, fails with error -10006, wrong size, wrong signature length configure mod_ssl: pass make apache: pass make certificate: pass make install for apache: pass Run apache without CryptoSwift card, using SSL, shmcb session cache: Testing with the Rainbow client program show, just one client. 1 thread: 22 tps 10 threads: 55 tps Run apache with CryptoSwift card, using SSL, shmcb session cache: 1 thread: 62tps 10 threads: 203tps Pass (Apache runs with this version of OpenSSL, the CryptoSwift card can still be accessed from OpenSSL, and it still accelerates SSL traffic). openssl-0.9.7-stable-SNAP-20021113 ../../include/openssl/aes.h, line 56: #error: AES is disabled. cc: acomp failed for aes-core.c *** Error code 2 make: Fatal error: Command failed for target aes_core.o I can also test snapshots on HP UX 11.0, AIX 4.3, and Linux Red Hat (a couple of different versions), if you need these. I will definitely check that the engine code changes in OpenSSL 0.9.7 don't break CryptoSwift, once I can get an OpenSSL 0.9.7 snapshot to build properly. Lynn Gazis Rainbow Technologies __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #29] -Wl,-Bsymbolic in 0.9.6d broke shared builds
On Thu, Nov 14, 2002 at 03:00:37PM +0100, Richard Levitte via RT wrote: [[EMAIL PROTECTED] - Sun May 12 22:48:56 2002]: JFYI, when updating our package from 0.9.6c to 0.9.6d I've noticed that the new shared libcrypto library doesn't work anymore. The openssl(1) binary wouldn't recognize any of the block ciphers. I tracked this down to the addition of -Wl,-Bsymbolic. Removing that option solved the problem for us. Hmm, if you, instead of removing that option, build and check the resulting library with 'nm', what exactly do you get? It's a mystery to me why things should go wrong for you. I've now tried removing the patch from our 0.9.6g package and what I get is: 1. Both versions appear to produce a working library now, however: 2. The sizes and symbol offsets in them differ: With -Wl,-Bsymbolic (original): -rwxr-xr-x root root 827429 Nov 15 09:28 /usr/lib/libcrypto.so.0.9.6 Without -Wl,-Bsymbolic (patched): -rwxr-xr-x root root 858309 Nov 15 09:40 /usr/lib/libcrypto.so.0.9.6 3. The sets of symbols (as reported by nm -a) are exactly the same. About the -Wl,-Bsymbolic problem, have you tried downloading a recent 0.9.6 snapshot and checked that the problem is still present? I haven't tried removing the patch from our package in further updates (to 0.9.6e and 0.9.6g), but have tried so now (see above). It does appear that the problem is gone, but I'd feel more comfortable knowing what made it go. One change to our package which could be relevant is this: * Wed Sep 25 2002 Solar Designer [EMAIL PROTECTED] - Don't do an explicit make build-shared, it's not needed and could only cause harm (link libssl against libcrypto statically), but luckily didn't; pointed out by Dmitry V. Levin of ALT Linux. Basically, with 0.9.6d we used to do: # Check these against the DIRS= line and all target in top-level Makefile # when updating to a new version of OpenSSL; with 0.9.6d the Makefile says: # DIRS= crypto ssl rsaref $(SHLIB_MARK) apps test tools # all: clean-shared Makefile.ssl sub_all make Makefile.ssl make sub_all DIRS=crypto ssl rsaref make build-shared LD_LIBRARY_PATH=`pwd` make sub_all DIRS=apps test tools Now this has changed to: # Check these against the DIRS= line and all target in top-level Makefile # when updating to a new version of OpenSSL; with 0.9.6g the Makefile says: # DIRS= crypto ssl rsaref $(SHLIB_MARK) apps test tools # all: clean-shared Makefile.ssl sub_all make Makefile.ssl make sub_all DIRS=crypto ssl rsaref LD_LIBRARY_PATH=`pwd` make sub_all DIRS=apps test tools -- /sd __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #261] [PATCHes] OpenSSL 0.9.6g: OBJ_txt2obj, EVP reinitialisation
Sounds good. -Original Message- From: Richard Levitte via RT [mailto:rt;openssl.org] Sent: Friday, 15 November 2002 10:25 AM To: Reddie, Steven Cc: [EMAIL PROTECTED] Subject: [openssl.org #261] [PATCHes] OpenSSL 0.9.6g: OBJ_txt2obj, EVP reinitialisation The OBJ_txt2obj() problem has already been solved. The EVP reinit problem is very easy to solve, actually. Somply remove the flag variable, which is exactly what has been decided within the team. I'm sure many will scream at this decision. However, think about it, the only way that flag variable is useful is to take care of people who can't keep track of what they've done already (have we already called OpenSSL_add_all_ciphers() or not?). Also, if someone is imagining that several threads could do some kind of reinitialization of the in-memory cipher and digest database, think again. That would be a really good way to screw things up. The only time OpenSSL_add_all_ciphers(), OpenSSL_add_all_digests() and EVP_cleanup() should be used is when the running program has only one thread. And if a single-threaded program reinits by calling EVP_cleanup() and then OpenSSL_add_all_*(), it works a lot better if the flag variable isn't hindering. Again, that requires that the programmer keeps track of what he or she is doing. The change is now committed, and this ticket is now resolved. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: IMPORTANT: Please try these specific snapshots
Thanks for doing the tests. I discoevered the AES problem myself yesterday, and I believe that the 1114 snapshot should work better, at least in that respect, so if you're willing, I'd like you to do the 0.9.7 tests again. And yes, the more platforms the merrier :-). In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 17:23:37 -0800, Lynn Gazis [EMAIL PROTECTED] said: lgazis Test of snapshots for 13 November 2002 lgazis lgazis Tests that were performed: lgazis lgazis - configuration and build lgazis - test suite lgazis - installation (be wise and do it in some temporary directory) lgazis lgazis Optional things would be to test the following: lgazis lgazis - build and run mod_ssl with the new installation lgazis lgazis Using mod_ssl 2.8.12 and Apache 1.3.27, with mm-1.2.1 lgazis lgazis (I am not testing OpenSSH or shared libraries. I am testing engine support lgazis for CryptoSwift, in conjunction with Apache.) lgazis lgazis lgazis On Solaris 7, using SUNWspro C compiler (Workshop C 5.0) lgazis (sun4u-whatever-solaris2), 32 bit lgazis (Path includes SUNWspro bin directory, /usr/ccs/bin, and /usr/openwin/bin, lgazis where makedepend is found.) lgazis lgazis OpenSSL 0.9.7 snapshot lgazis lgazis openssl-SNAP-20021113: lgazis lgazis config - pass lgazis make depend - pass lgazis make - FAILED lgazis lgazis ../../include/openssl/aes.h, line 56: #error: AES is disabled. lgazis cc: acomp failed for aes-core.c lgazis *** Error code 2 lgazis make: Fatal error: Command failed for target aes_core.o lgazis lgazis lgazis openssl-e-0.9.6-stable-SNAP-20021113: lgazis lgazis config: pass, configured for solaris-sparcv9-cc lgazis make: pass lgazis make test: pass (with the exception of bc, which cleanly fails for lack of lgazis the right version of bc on this system) lgazis speed test: accesses cswift engine, fails with error -10006, wrong size, lgazis wrong signature length lgazis configure mod_ssl: pass lgazis make apache: pass lgazis make certificate: pass lgazis make install for apache: pass lgazis Run apache without CryptoSwift card, using SSL, shmcb session cache: lgazis Testing with the Rainbow client program show, just one client. lgazis 1 thread: 22 tps lgazis 10 threads: 55 tps lgazis Run apache with CryptoSwift card, using SSL, shmcb session cache: lgazis 1 thread: 62tps lgazis 10 threads: 203tps lgazis Pass (Apache runs with this version of OpenSSL, the CryptoSwift card can lgazis still be accessed from OpenSSL, and it still accelerates SSL traffic). lgazis lgazis openssl-0.9.7-stable-SNAP-20021113 lgazis lgazis ../../include/openssl/aes.h, line 56: #error: AES is disabled. lgazis cc: acomp failed for aes-core.c lgazis *** Error code 2 lgazis make: Fatal error: Command failed for target aes_core.o lgazis lgazis I can also test snapshots on HP UX 11.0, AIX 4.3, and Linux Red Hat (a lgazis couple of different versions), if you need these. I will definitely check lgazis that the engine code changes in OpenSSL 0.9.7 don't break CryptoSwift, once lgazis I can get an OpenSSL 0.9.7 snapshot to build properly. lgazis lgazis Lynn Gazis lgazis Rainbow Technologies -- 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]
