[openssl.org #1180] NetWare patch to add gcc support to 0.9.8
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1107] NetWare patch for 0.9.8-beta4
diff -cr openssl-0.9.8-beta4.clean/apps/s_socket.c
openssl-0.9.8-beta4/apps/s_socket.c
*** openssl-0.9.8-beta4.clean/apps/s_socket.c Tue Apr 26 17:43:52 2005
--- openssl-0.9.8-beta4/apps/s_socket.c Thu Jun 09 20:02:39 2005
***
*** 87,94
#ifndef OPENSSL_NO_SOCK
static struct hostent *GetHostByName(char *name);
! #if defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_NETWARE)
static void ssl_sock_cleanup(void);
#endif
static int ssl_sock_init(void);
--- 87,98
#ifndef OPENSSL_NO_SOCK
+ #if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_BSDSOCK)
+ #include "netdb.h"
+ #endif
+
static struct hostent *GetHostByName(char *name);
! #if defined(OPENSSL_SYS_WINDOWS) || (defined(OPENSSL_SYS_NETWARE) &&
!defined(NETWARE_BSDSOCK))
static void ssl_sock_cleanup(void);
#endif
static int ssl_sock_init(void);
***
*** 104,110
#define SOCKET_PROTOCOL IPPROTO_TCP
#endif
! #ifdef OPENSSL_SYS_NETWARE
static int wsa_init_done=0;
#endif
--- 108,114
#define SOCKET_PROTOCOL IPPROTO_TCP
#endif
! #if defined(OPENSSL_SYS_NETWARE) && !defined(NETWARE_BSDSOCK)
static int wsa_init_done=0;
#endif
***
*** 156,162
WSACleanup();
}
}
! #elif defined(OPENSSL_SYS_NETWARE)
static void sock_cleanup(void)
{
if (wsa_init_done)
--- 160,166
WSACleanup();
}
}
! #elif defined(OPENSSL_SYS_NETWARE) && !defined(NETWARE_BSDSOCK)
static void sock_cleanup(void)
{
if (wsa_init_done)
***
*** 199,205
SetWindowLong(topWnd,GWL_WNDPROC,(LONG)lpTopHookProc);
#endif /* OPENSSL_SYS_WIN16 */
}
! #elif defined(OPENSSL_SYS_NETWARE)
WORD wVerReq;
WSADATA wsaData;
int err;
--- 203,209
SetWindowLong(topWnd,GWL_WNDPROC,(LONG)lpTopHookProc);
#endif /* OPENSSL_SYS_WIN16 */
}
! #elif defined(OPENSSL_SYS_NETWARE) && !defined(NETWARE_BSDSOCK)
WORD wVerReq;
WSADATA wsaData;
int err;
***
*** 398,404
ret=accept(acc_sock,(struct sockaddr *)&from,(void *)&len);
if (ret == INVALID_SOCKET)
{
! #if defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_NETWARE)
i=WSAGetLastError();
BIO_printf(bio_err,"accept error %d\n",i);
#else
--- 402,408
ret=accept(acc_sock,(struct sockaddr *)&from,(void *)&len);
if (ret == INVALID_SOCKET)
{
! #if defined(OPENSSL_SYS_WINDOWS) || (defined(OPENSSL_SYS_NETWARE) &&
!defined(NETWARE_BSDSOCK))
i=WSAGetLastError();
BIO_printf(bio_err,"accept error %d\n",i);
#else
diff -cr openssl-0.9.8-beta4.clean/Configure openssl-0.9.8-beta4/Configure
*** openssl-0.9.8-beta4.clean/Configure Sun Jun 05 22:19:34 2005
--- openssl-0.9.8-beta4/Configure Fri Jun 10 16:53:19 2005
***
*** 486,492
--- 486,495
# netware-clib => legacy CLib c-runtime support
"netware-clib", "mwccnlm::BN_LLONG ${x86_gcc_opts}::",
# netware-libc => LibC/NKS support
+ # NetWare defaults socket bio to WinSock sockets. However, the LibC build can
be
+ # configured to use BSD sockets instead.
"netware-libc", "mwccnlm::BN_LLONG ${x86_gcc_opts}::",
+ "netware-libc-bsdsock", "mwccnlm::BN_LLONG ${x86_gcc_opts}::",
"netware-libc-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include
-I/ndk/libc/include/winsock -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE
-DTERMIO -O2 -Wall:BN_LLONG ${x86_gcc_opts}::",
# DJGPP
***
*** 530,536
my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A
VC-NT VC-CE VC-WIN32
! BC-32 OS2-EMX netware-clib netware-libc);
my $idx = 0;
my $idx_cc = $idx++;
--- 533,539
my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A
VC-NT VC-CE VC-WIN32
! BC-32 OS2-EMX netware-clib netware-libc
netware-libc-bsdsock);
my $idx = 0;
my $idx_cc = $idx++;
diff -cr openssl-0.9.8-beta4.clean/crypto/bio/b_sock.c
openssl-0.9.8-beta4/crypto/bio/b_sock.c
*** openssl-0.9.8-beta4.clean/crypto/bio/b_sock.c Sat Dec 27 14:40:12 2003
--- openssl-0.9.8-beta4/crypto/bio/b_sock.c Thu Jun 09 19:58:44 2005
***
*** 62,67
--- 62,70
#define USE_SOCKETS
#include "cryptlib.h"
#include
+ #if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_BSDSOCK)
+ #include "netdb.h"
+ #endif
#ifndef OPENSSL_NO_SOCK
***
*** 79,85
#define MAX_LISTEN 32
#endif
! #if defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_NETWARE)
static int wsa_init_done=0;
#endif
--- 82,88
#define MAX_LISTEN 32
#endif
! #if defined(OPENSSL_SYS_WINDOWS) || (defined(OPENSSL_SYS_NETWARE) &&
!defined(NETWARE_BSDSOCK))
static int wsa_init_done=0;
#endif
***
*** 474,480
Re: [openssl.org #1043] Updated 0.9.7g NetWare Patch for the Contribution page
This is marked fixed, but checking the website again today shows it still has the old patch from 0.9.7d. Is there something else that needs to happen? Thanks. Verdon >>> [EMAIL PROTECTED] 6/5/2005 5:48:03 PM >>> Added the 0.9.7g diff. Thanks! Ticket resolved. -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1043] Updated 0.9.7g NetWare Patch for the Contribution page
This is marked fixed, but checking the website again today shows it still has the old patch from 0.9.7d. Is there something else that needs to happen? Thanks. Verdon>>> [EMAIL PROTECTED] 6/5/2005 5:48:03 PM >>> Added the 0.9.7g diff. Thanks!Ticket resolved.-- Richard Levitte[EMAIL PROTECTED]__OpenSSL Project http://www.openssl.orgDevelopment Mailing List openssl-dev@openssl.orgAutomated List Manager [EMAIL PROTECTED]
[openssl.org #1098] NetWare patch for 0.9.8-beta3
diff -cr openssl-0.9.8-beta3/Configure openssl-0.9.8-beta3.nw/Configure
*** openssl-0.9.8-beta3/Configure Wed May 18 02:17:26 2005
--- openssl-0.9.8-beta3.nw/Configure Thu Jun 2 11:05:34 2005
***
*** 484,493
# NetWare from David Ward ([EMAIL PROTECTED]) - requires MetroWerks NLM
development tools
# netware-clib => legacy CLib c-runtime support
! "netware-clib", "mwccnlm:${x86_gcc_opts}:::",
# netware-libc => LibC/NKS support
! "netware-libc", "mwccnlm:BN_LLONG ${x86_gcc_opts}:::",
! "netware-libc-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include
-I/ndk/libc/include/winsock -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE
-DTERMIO -O2 -Wall${x86_gcc_opts}:::",
# DJGPP
"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN
-fomit-frame-pointer -O2 -Wall
-DDEVRANDOM=\"/dev/urandom\\x24\":::MSDOS:-L/dev/env/WATT_ROOT/lib
-lwatt:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_out_asm}:",
--- 484,493
# NetWare from David Ward ([EMAIL PROTECTED]) - requires MetroWerks NLM
development tools
# netware-clib => legacy CLib c-runtime support
! "netware-clib", "mwccnlm::BN_LLONG ${x86_gcc_opts}::",
# netware-libc => LibC/NKS support
! "netware-libc", "mwccnlm::BN_LLONG ${x86_gcc_opts}::",
! "netware-libc-gcc", "i586-netware-gcc:-nostdinc -I/ndk/libc/include
-I/ndk/libc/include/winsock -DL_ENDIAN -DNETWARE_LIBC -DOPENSSL_SYSNAME_NETWARE
-DTERMIO -O2 -Wall:BN_LLONG ${x86_gcc_opts}::",
# DJGPP
"DJGPP", "gcc:-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN
-fomit-frame-pointer -O2 -Wall
-DDEVRANDOM=\"/dev/urandom\\x24\":::MSDOS:-L/dev/env/WATT_ROOT/lib
-lwatt:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_out_asm}:",
diff -cr openssl-0.9.8-beta3/e_os.h openssl-0.9.8-beta3.nw/e_os.h
*** openssl-0.9.8-beta3/e_os.h Sat May 21 07:19:44 2005
--- openssl-0.9.8-beta3.nw/e_os.h Fri Jun 3 14:36:32 2005
***
*** 438,448
# elif defined(OPENSSL_SYS_NETWARE)
/* NetWare uses the WinSock2 interfaces
*/
! # if defined(NETWARE_CLIB)
! #include
! # elif defined(NETWARE_LIBC)
! #include
! # endif
# define SSLeay_Write(a,b,c) send((a),(b),(c),0)
# define SSLeay_Read(a,b,c) recv((a),(b),(c),0)
# define SHUTDOWN(fd){ shutdown((fd),0); closesocket(fd); }
--- 438,444
# elif defined(OPENSSL_SYS_NETWARE)
/* NetWare uses the WinSock2 interfaces
*/
! # include
# define SSLeay_Write(a,b,c) send((a),(b),(c),0)
# define SSLeay_Read(a,b,c) recv((a),(b),(c),0)
# define SHUTDOWN(fd){ shutdown((fd),0); closesocket(fd); }
Only in openssl-0.9.8-beta3.nw: inc32
diff -cr openssl-0.9.8-beta3/INSTALL.NW openssl-0.9.8-beta3.nw/INSTALL.NW
*** openssl-0.9.8-beta3/INSTALL.NW Mon Jun 28 05:55:28 2004
--- openssl-0.9.8-beta3.nw/INSTALL.NW Fri Jun 3 15:33:10 2005
***
*** 95,103
Microsoft SDK. Note: The winsock2.h support headers may change
with various versions of winsock2.h. Check the dependencies
section on the NDK WinSock2 download page for the latest
! information on dependencies.
NLM and NetWare libraries for C (including CLIB and XPlat):
If you are going to build a CLIB version of OpenSSL, you will
need the CLIB headers and imports. The March, 2001 NDK release or
--- 95,108
Microsoft SDK. Note: The winsock2.h support headers may change
with various versions of winsock2.h. Check the dependencies
section on the NDK WinSock2 download page for the latest
! information on dependencies. These components are unsupported by
! Novell. They are provided as a courtesy, but it is strongly
! suggested that all development be done using LIBC, not CLIB.
+ As of June 2005, the WinSock2 components are available at:
+ http://forgeftp.novell.com//ws2comp/
+
NLM and NetWare libraries for C (including CLIB and XPlat):
If you are going to build a CLIB version of OpenSSL, you will
need the CLIB headers and imports. The March, 2001 NDK release or
***
*** 287,299
The do_tests.pl script generates a log file "\openssl\test_out\tests.log"
which should be reviewed for errors. Any errors will be denoted by the word
"ERROR" in the log.
-
- NOTE: Currently (11/2002), the LibC test nlms report an error while loading
-when launched from the perl script (do_tests.pl). The problems are
-being addressed by the LibC development team and should be fixed in the
-next release. Until the problems are corrected, the LibC test nlms
-will have to be executed manually.
-
DEVELOPING WITH THE OPENSSL SDK:
--- 292,297
diff -cr openssl-0.9.8-beta3/Netware/do_tests.pl
openssl-0.9.8-beta3.nw/Netware/do_tests.pl
*** openssl-0.9.8
Re: [openssl.org #1043] Updated 0.9.7g NetWare Patch for the Contribution page
In updating the NetWare patch for 0.9.8, I also noticed that my latest 0.9.7g NetWare patch has not been added to the "Contributions" page. Is it possible to have that happen as well? Thanks for everything. Verdon
Root level Makefile and Makefile.bak in tarball for 0.9.7e
It looks like a couple of extra files hitched a ride in the latest 0.9.7e tarball. Unless I am mistaken, the root level directory has a "Makefile" and "Makefile.bak" that shouldn't be there since "Makefile" is created automatically from "Makefile.org".
Re: [openssl.org #781] [PATCH] NetWare Support for OpenSSL 0.9.7
I did not realize that ERR_remove_state() worked that way. In looking at the code, it appears that it does indeed delete the table making ERR_free_state_table() unnecessary in properly coded applications. Thanks. Verdon>>> "Richard Levitte via RT" <[EMAIL PROTECTED]> 6/28/2004 5:47:58 AM >>> Just a comment on what I just wrote...[levitte - Mon Jun 28 13:37:50 2004]:> I've looked back at the ERR_free_state_table() discussion, and I can't > find any message where we came to a resolution. Looking at the patch > right now, I still fail to see what that function does that > ERR_remove_state() doesn't. It should be noted that ERR_remove_state() > *does* remove the whole table when there are no more references to it. > The way it's supposed to work is that it should be called at the end of > each thread (including the main one). My stand on this issue hasn't > changed since we discussed it last.If ERR_remove_state() doesn't work as it should (as said above), then it's a bug in ERR_remove_state() and should be treated that way, and therefore result in a fix of ERR_remove_state(). IMHO.-- Richard Levitte[EMAIL PROTECTED]
[openssl.org #903] [PATCH] Defect fix for NetWare Support in OpenSSL 0.9.8
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #902] Updated NetWare Patch for the Contribution page
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #781] [PATCH] NetWare Support for OpenSSL 0.9.7
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSE2 code in OpenSSL
I queried a guru here at work and got the following response: It is the responsibility of the OS to indicate to the CPU that it supports SSE2 instructions by setting the OSFXSR bit in CR4. If they are running a legacy OS that doesn't support SSE2 (meaning that it isn't using the FXSAVE and FXRSTOR instructions during context switches) then the OSFXSR bit won't be set. When the OSFXSR bit is not set, the SSE2 instructions aren't available; if you try to execute one, you will get an invalid opcode exception - even if you are running on the latest CPUs that support SSE2. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell, Inc., the leading provider of information solutionshttp://www.novell.com >>> [EMAIL PROTECTED] 5/21/2004 11:46:20 AM >>> A work is being done toward adopting IA-32 SSE2 code pathes in OpenSSL: bn_mul_add_words and SHA-512 at present. Whether or not a path is taken is decided at run-time. Formally the decision is be taken upon two factors: CPU capability and kernel support for SSE extentions. As it doesn't appear feasable to detect the latter in a way we're ready to support on multiple platforms, we choose to lift this responsibility to end user. The user will have the option to either set an environment variable prior starting the application or recompile the toolkit without SSE2 support.However! Above is not the actual matter of this query to the developer community:-) While re-examining the IA-32 instruction reference I ran into following question. What does kernel support mean exactly? Kernel is expected to set a flag in privileged control register to denote its intention to preserve XMM register bank content upon process context switch. And *now* the question itself. What about SSE2 intructions issued with MM register as argument? MM registers are aliased to FP bank, which is preserved upon context switch even by elder kernels. Would SSE2 instruction cause invalid opcode exception under legacy kernel even if issued with MM register as argument? The catch is that at least bn_mul_add_words uses exclusively MM register bank, in which case check for CPU capability alone would suffice. Does anybody know answer by hard or has a system with some legacy OS in her/his disposal we could test this on? A.__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Re: SHA-256/-384/-512, Netware...
"As we all know" excludes me so I talked to one of our experts here to find out the answer to your questions. This was his response: [Embedded Response] NetWare supports SSE2 up to a point. NetWare assumes that the XMM registers are scratch registers across procedure calls. NetWare preserves the XMM registers during a pre-emptive context switch. NetWare also does the basic CPU setup so that XMM can be used. Since NetWare 6.X supports Pentium II and newer CPUs, it needs to run on platforms that don't support SSE2. Since NetWare based applications are usually delivered in executable form rather than source code, programs that uses SSE and SSE2 need to detect what type of processor it is running on and adjust accordingly. The 2 main ways of doing this are 1) deliver different versions of the software - one with support for SSE2 and the other without - and have the installation software install the appropriate version; or 2) have the code be dynamic and detect the CPU type when it runs and adjust itself as necessary. [/Embedded Response] I hope that answers the questions. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> Andy Polyakov <[EMAIL PROTECTED]> 5/6/2004 6:36:06 AM >>> > I've handcoded > SSE2 SHA512_Transform which exhibits almost 6x performance improvement > [of course the result is preliminary] on P4 over gcc compiled code, I've commited the code to CVS even though it's nowhere to plug it in for the moment. The code is therefore subject to change as C implementation is added. But in either case! Following question not directly related to SHA was risen. Adding of SSE2 code required update to crypto/perlasm modules. I've updated x86unix.pl, x86ms.pl and x86nasm.pl, but not the Netware scripts. As we all know SSE requires kernel support (kernel is expected to set-up a privileged control register and preserve xmm content over context switches). Does Netware support SSE in the above sense? Do Netware assemblers support SSE2? In other words is it of actual interest to update Netware scripts? If it is, then I would actually prefer to either merge them to one script or even with x86nasm.pl script. I reckon that differences between them are too small and can be addressed in single script. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Regarding crypto/md32_common.h
I had already made the change you suggest even before reading your
email. It works great with the latest Metrowerks compiler.
Unfortunately, further testing with older versions of the compiler (the
only one available when the code was first ported to NetWare) produced
undefined symbols for "__rol". I'm not sure what exactly changed in the
newer version of Metrowerks, but we do want to support both versions of
the compiler (at least for now).
Verdon
>>> Andy Polyakov <[EMAIL PROTECTED]> 3/19/2004 7:25:59 AM >>>
> BTW, _MSC_VER was not
> defined so I changed it to __NETWARE__ which was defined (to my
> surprise):
Defined or not seems to be irrelevant. Indeed, __rol intrinsic is the
one which is implemented and it should have beed engaged as it was
(i.e.
without check for a Netware specific macro, pre-defined or not):
> int foo(int a) { return _lrotl(a,1+_MSC_VER); }
> 0008: E8 call _lrotl
>
> int bar(int a) { return __rol(a,1+__MWERKS__); }
> 0006: C1C007 rol eax,0x7
Verdon, can you confirm that it works without #elif
defined(OPENSSL_SYSNAME_NETWARE) in __MWERKS__ section of
crypto/md32_common.h? It should:-) A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Regarding crypto/md32_common.h
Here's the assembly output for the two funtions. BTW, _MSC_VER was not
defined so I changed it to __NETWARE__ which was defined (to my
surprise):
foo:
: 55 push ebp
0001: 89E5 mov ebp,esp
0003: 6A02 push 0x2
0005: FF7508 push dword ptr [ebp+0x8]
0008: E8 call _lrotl
000d: 59 pop ecx
000e: 59 pop ecx
000f: 89C0 mov eax,eax ;
align
0011: C9 leave
0012: C3 ret near
bar:
: 55 push ebp
0001: 89E5 mov ebp,esp
0003: 8B4508 mov eax,dword ptr [ebp+0x8]
0006: C1C007 rol eax,0x7
0009: C9 leave
000a: C3 ret near
Verdon
>>> Andy Polyakov <[EMAIL PROTECTED]> 3/15/2004 3:24:18 PM >>>
> There is a Metrowerks compiler for NetWare. It is actually a
> cross-compiler that runs on a Win32 platform and then uses a
different
> linker to create the libraries. As near as I know, "__NETWARE__" is
not
> defined when compiling.
But is there __rol intrinsic? Can you generate assembler listing (and
send it over:-) for following snippet:
int foo(int a) { return _lrotl(a,1+_MSC_VER); }
int bar(int a) { return __rol(a,1+__MWERKS__); }
You might have to engage optimization. A lot of thanks in advance. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Regarding crypto/md32_common.h
There is a Metrowerks compiler for NetWare. It is actually a cross-compiler that runs on a Win32 platform and then uses a different linker to create the libraries. As near as I know, "__NETWARE__" is not defined when compiling. Hence, we use the "OPENSSL_SYSNAME_NETWARE" that has been set up for use with OpenSSL in general. I hope this answers the question. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> Andy Polyakov <[EMAIL PROTECTED]> 3/12/2004 4:49:47 PM >>> crypto/md32_common.h currently reads: # if 0 /* defined(_MSC_VER) */ # define ROTATE(a,n) _lrotl(a,n) # elif defined(__MWERKS__) # if defined(__POWERPC__) # define ROTATE(a,n) __rlwinm(a,n,0,31) # elif defined(OPENSSL_SYSNAME_NETWARE) # define ROTATE(a,n) _lrotl(a,n) ... First #if was zapped with "_lrotl() is a call to the C runtime library! By ulf." comment. Well, _lrotl is a call only as long as optimization for speed is off. As we compile with /Ox, _lrotl is treated as intrinsic and *is* compiled as inline instruction. As for OPENSSL_SYSNAME_NETWARE in __MWERKS__ context. I didn't know that there is/was Metrowerks compiler for Netware... But in either case current Metrowerks documentation doesn't mention _lrotl, but __rol on Intel platform(s). Then if you google for "+_lrotl +metrowerks," you find a statement that Metrowerks defines _MSC_VER, but not _lrotl. Note that current Metrowerks documentation doesn't mention _MSC_VER macro either. So I'm lost... Also note that other #if-s in __MWERKS__ section rely on compiler predefines, which is preferred. Is there a Netware-specific predefine? Where am I heading? If __NETWARE__ was Netware-specific prefefine, wouldn't following be more appropriate: #if defined(__MWERKS__) # if defined(__NETWARE__) # define ROTATE(a,n) _lrotl(a,n) # elif # ... # endif #elif defined(_MSC_VER) # define ROTATE(a,n) _lrotl(a,n) ... A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #781] [PATCH] NetWare Support for OpenSSL 0.9.7
Richard, Any chance yet to reconsider applying this patch to 0.9.7? Verdon >>> [EMAIL PROTECTED] 12/2/2003 3:38:32 PM >>> Addressing the points in order: ERR_free_state_table() is not meant to do the same as ERR_remove_state(). It is indeed meant to clean up the entire table and is used for process cleanup, not thread cleanup. NetWare will clean up process resources, but does complain when you don't clean up after yourself. The whole issue of library cleanup is best addressed, however, as a separate topic rather than followup on this particular patch so I will do so in a separate email. I was not aware that crypto/des/read_pwd.c was not in use anymore. This change was pulled forward from our 0.9.6 changes. Thanks for the info. The removal of EVP_MD_CTX_cleanup() in crypto/mdc2/mdc2test.c was indeed an oversight. Yes, it is our intent to continue to support these changes in future versions of OpenSSL including building and testing them in each release (and pre-release) of OpenSSL. Thank you so VERY much for your consideration of this work! Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> [EMAIL PROTECTED] 11/28/2003 5:39:44 AM >>> [EMAIL PROTECTED] - Thu Nov 27 09:23:09 2003]: > This patch adds support for the NetWare OS to OpenSSL 0.9.7. After > applying this patch, the instructions for building for NetWare can be > found in the "INSTALL.NW" file in the root directory. This patch > attempts to minimize impact on other platforms through the judicious > use > of the preprocessor guard "OPENSSL_SYS_NETWARE". It does introduce one > new general purpose function "ERR_free_state_table" which we found > useful when cleaning up threads. I'm not sure I understand the need for ERR_free_state_table(). It seems to me that ERR_remove_state() performs the same operation, but makes sure that only the state of the current thread is cleaned (int_thread_del_item() will free that whole hash table when the last thread runs it). To be perfectly clear, it seems to me like ERR_free_state_table() would be disastrous to use in a threaded environment, or at least very potentially so. I will therefore reject the changes to crypto/err/err. c, crypto/err/err.h and util/libeay.num. There are a few more issues, although comparatively minor: 1. Do you know that crypto/des/read_pwd.c isn't used at all any more? It can safely be ignored. I will therefore reject your changes to that file. 2. In crypto/mdc2/mdc2test.c, I notice you removed the call to EVP_MD_CTX_cleanup() on line 142. Was there a reason for that, or is it just a typo? 3. Will you help us maintain these changes in future versions of OpenSSL, or is there a risk that the new files will age quickly? > I have applied the patch to the latest 0.9.7c source and built for > both > NetWare and Windows. The test suite runs correctly on both platforms > with the patch applied. > > I understand that active development on the 0.9.7 code is limited. > These changes, however, have minimal impact on existing code and I > hope > you will consider them. If the patch is not accepted for 0.9.7, I > request that this patch file be added to the "Contributions" page in > the > same manner as the 0.9.6 NetWare patch. I will place the patch kit, with the rejected changes removed, in the contribution directory for now. I'm keeping this ticket open and will await your answer to my issues. I will also check with the other developpers if they have some issues with this change. After that, I will reconsider the application of the change. I'm making no promisses, though. -- Richard Levitte [EMAIL PROTECTED] __ 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 Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #784] Library cleanup functionality
Although OpenSSL has an initialization routine (SSL_library_init), it does not have a corresponding cleanup routine (SSL_library_cleanup). It does have a few cleanup routines (e.g. EVP_cleanup, OBJ_cleanup, etc.) but no overall cleanup function. This has been an issue for us when running OpenSSL on NetWare. Although NetWare will clean up the resources when a process goes away, it does complain about unfreed resources before doing so. It is not clear if there is a proper way to clean up the library resources when you are done with them. For instance, you can clean up any entries in the error queue for a thread by calling ERR_remove_state(). However, there is no way to actually clean up and free the queue itself. We added a routine to do that on NetWare, but there is some reluctance to accept it into the main body of code because it would naturally be a very dangerous function if called inappropriately. What are people's thoughts on the matter? Should OpenSSL formalize a mechanism for cleaning up global library resources? Or is it sufficient to let the OS do that work? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ 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]
Library cleanup functionality
Although OpenSSL has an initialization routine (SSL_library_init), it does not have a corresponding cleanup routine (SSL_library_cleanup). It does have a few cleanup routines (e.g. EVP_cleanup, OBJ_cleanup, etc.) but no overall cleanup function. This has been an issue for us when running OpenSSL on NetWare. Although NetWare will clean up the resources when a process goes away, it does complain about unfreed resources before doing so. It is not clear if there is a proper way to clean up the library resources when you are done with them. For instance, you can clean up any entries in the error queue for a thread by calling ERR_remove_state(). However, there is no way to actually clean up and free the queue itself. We added a routine to do that on NetWare, but there is some reluctance to accept it into the main body of code because it would naturally be a very dangerous function if called inappropriately. What are people's thoughts on the matter? Should OpenSSL formalize a mechanism for cleaning up global library resources? Or is it sufficient to let the OS do that work? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #781] [PATCH] NetWare Support for OpenSSL 0.9.7
Addressing the points in order: ERR_free_state_table() is not meant to do the same as ERR_remove_state(). It is indeed meant to clean up the entire table and is used for process cleanup, not thread cleanup. NetWare will clean up process resources, but does complain when you don't clean up after yourself. The whole issue of library cleanup is best addressed, however, as a separate topic rather than followup on this particular patch so I will do so in a separate email. I was not aware that crypto/des/read_pwd.c was not in use anymore. This change was pulled forward from our 0.9.6 changes. Thanks for the info. The removal of EVP_MD_CTX_cleanup() in crypto/mdc2/mdc2test.c was indeed an oversight. Yes, it is our intent to continue to support these changes in future versions of OpenSSL including building and testing them in each release (and pre-release) of OpenSSL. Thank you so VERY much for your consideration of this work! Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> [EMAIL PROTECTED] 11/28/2003 5:39:44 AM >>> [EMAIL PROTECTED] - Thu Nov 27 09:23:09 2003]: > This patch adds support for the NetWare OS to OpenSSL 0.9.7. After > applying this patch, the instructions for building for NetWare can be > found in the "INSTALL.NW" file in the root directory. This patch > attempts to minimize impact on other platforms through the judicious > use > of the preprocessor guard "OPENSSL_SYS_NETWARE". It does introduce one > new general purpose function "ERR_free_state_table" which we found > useful when cleaning up threads. I'm not sure I understand the need for ERR_free_state_table(). It seems to me that ERR_remove_state() performs the same operation, but makes sure that only the state of the current thread is cleaned (int_thread_del_item() will free that whole hash table when the last thread runs it). To be perfectly clear, it seems to me like ERR_free_state_table() would be disastrous to use in a threaded environment, or at least very potentially so. I will therefore reject the changes to crypto/err/err. c, crypto/err/err.h and util/libeay.num. There are a few more issues, although comparatively minor: 1. Do you know that crypto/des/read_pwd.c isn't used at all any more? It can safely be ignored. I will therefore reject your changes to that file. 2. In crypto/mdc2/mdc2test.c, I notice you removed the call to EVP_MD_CTX_cleanup() on line 142. Was there a reason for that, or is it just a typo? 3. Will you help us maintain these changes in future versions of OpenSSL, or is there a risk that the new files will age quickly? > I have applied the patch to the latest 0.9.7c source and built for > both > NetWare and Windows. The test suite runs correctly on both platforms > with the patch applied. > > I understand that active development on the 0.9.7 code is limited. > These changes, however, have minimal impact on existing code and I > hope > you will consider them. If the patch is not accepted for 0.9.7, I > request that this patch file be added to the "Contributions" page in > the > same manner as the 0.9.6 NetWare patch. I will place the patch kit, with the rejected changes removed, in the contribution directory for now. I'm keeping this ticket open and will await your answer to my issues. I will also check with the other developpers if they have some issues with this change. After that, I will reconsider the application of the change. I'm making no promisses, though. -- Richard Levitte [EMAIL PROTECTED] __ 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 #780] [PATCH] NetWare Support for OpenSSL 0.9.8
This patch adds support for the NetWare OS to OpenSSL 0.9.8. After applying this patch, the instructions for building for NetWare can be found in the "INSTALL.NW" file in the root directory. This patch attempts to minimize impact on other platforms through the judicious use of the preprocessor guard "OPENSSL_SYS_NETWARE". It does introduce one new general purpose function "ERR_free_state_table" which we found useful when cleaning up threads. I have applied the patch to the latest 0.9.8 development snapshots (11-24-2003) and built for both NetWare and Windows. The test suite runs correctly on both platforms with the patch applied. Thank you for your consideration of this work. Note: This is a repeat of a request made in June. The patch file has been updated, however, to address a couple of minor issues. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #781] [PATCH] NetWare Support for OpenSSL 0.9.7
This patch adds support for the NetWare OS to OpenSSL 0.9.7. After applying this patch, the instructions for building for NetWare can be found in the "INSTALL.NW" file in the root directory. This patch attempts to minimize impact on other platforms through the judicious use of the preprocessor guard "OPENSSL_SYS_NETWARE". It does introduce one new general purpose function "ERR_free_state_table" which we found useful when cleaning up threads. I have applied the patch to the latest 0.9.7c source and built for both NetWare and Windows. The test suite runs correctly on both platforms with the patch applied. I understand that active development on the 0.9.7 code is limited. These changes, however, have minimal impact on existing code and I hope you will consider them. If the patch is not accepted for 0.9.7, I request that this patch file be added to the "Contributions" page in the same manner as the 0.9.6 NetWare patch. Thank you for your consideration of this work. Note: This is a repeat of a request made in June. The patch file has been updated, however, to address a couple of minor issues discovered when migrating to OpenSSL 0.9.7c. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
A few minor issues building 0.9.8 for Windows
I recently downloaded and compiled for Windows the 0.9.8 snapshot from 11-24-2003. I had a few minor problems of which you might want to be aware: .\crypto\bio\bss_file.c(218) : error C2065: 'fd' : undeclared identifier NMAKE : fatal error U1077: 'cl' : return code '0x2' .\crypto\bio\b_print.c(646) : error C2220: warning treated as error - no object file generated .\crypto\bio\b_print.c(646) : warning C4244: '-=' : conversion from 'double ' to 'long ', possible loss of data NMAKE : fatal error U1077: 'cl' : return code '0x2' LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_gmp out32dll.dbg\libeay32.lib : fatal error LNK1120: 1 unresolved externals LINK : fatal error LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' SSLEAY32.def : error LNK2001: unresolved external symbol SSL_COMP_get_compression_method out32dll.dbg\ssleay32.lib : fatal error LNK1120: 1 unresolved externals LINK : fatal error LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Defect? regarding Session ID's
Thanks for the information. Verdon Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> [EMAIL PROTECTED] 09/26/03 7:08 PM >>> On Fri, Sep 26, 2003, Verdon Walker wrote: > I noticed a small inconsistency in OpenSSL. > > According to the OpenSSL documentation, applications that want to > resume sessions should call "SSL_CTX_set_session_id_context()" to > provide a unique identifier to be stored with their session caches. > > However, observing the behavior of OpenSSL and looking at the following > code (ssl_sess.c : ssl_get_prev_session): > > if((s->verify_mode&SSL_VERIFY_PEER) > && (!s->sid_ctx_length || ret->sid_ctx_length != s->sid_ctx_length > || memcmp(ret->sid_ctx,s->sid_ctx,ret->sid_ctx_length))) > > it appears that session id's are not always checked when resuming > sessions. For a server implementation, they are only checked if mutual > authentication is turned on. > > The code should really either check the session id anytime it is being > reused or ignore it always if it is not set. I'm not sure which is > better, but I am sure the code should be consistent. > This is actually there to protect against a case where a malicious client could resume a session in an inappropriate context. This only affects sessions that enable client authentication so it is only checked in those cases. This was addressed way back in March 1999. For more details see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ 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]
Defect? regarding Session ID's
I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call "SSL_CTX_set_session_id_context()" to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s->verify_mode&SSL_VERIFY_PEER) && (!s->sid_ctx_length || ret->sid_ctx_length != s->sid_ctx_length || memcmp(ret->sid_ctx,s->sid_ctx,ret->sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
A couple more FIPS questions
I have downloaded the latest FIPS snapshot (9/9) and I have a couple more questions about it: 1) How do I build it? If I just do a "./config" (Linux) and "make", it will build everything, but I'm not sure I'm getting all the FIPS stuff. Do I need to specify something like "./config -DFIPS" to get it to build the FIPS cryptography module? 2) It doesn't appear that optimized assembly code is part of the FIPS module. Is that correct? 3) Once I have the FIPS crypto built, how do I use OpenSSL so that all SSL crypto work is done using that FIPS crypto? Thanks. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FIPS mode
After reviewing the email archives for both the developer and user groups, I have a lot of questions: - What platforms are being FIPS certified? - Is it FIPS 140-2? - What version of OpenSSL does it correspond to? 0.9.7b? - Are both the static libraries and dynamic libraries to be certified? If not, which? - What is the strategy for introducing bug fixes into the FIPS OpenSSL? - etc. Basically, I would like to know a lot more about what has happened so far, where the certification process is, etc. The threads in the email archives basically show that doing the work was discussed, but not really settled. Then suddenly a note that the code has been moved to its own branch and now this message saying it's almost too late to have any input. What happened to the discussion about the ongoing work? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> [EMAIL PROTECTED] 9/4/2003 5:11:23 AM >>> I'm coming close to the end of the work to get OpenSSL FIPS-140ed. So, if people have comments/changes/concerns, they'd better get a move on and clue me in, because once its done we can't change it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare Support for OpenSSL 0.9.8
I hate to be a pest, but has anything changed on this? Verdon >>> [EMAIL PROTECTED] 7/7/2003 11:07:00 PM >>> In message <[EMAIL PROTECTED]> on Mon, 07 Jul 2003 13:10:39 -0600, "Verdon Walker" <[EMAIL PROTECTED]> said: VWalker> Has anyone had a chance to look at this patch yet? Is it on VWalker> anyone's "to do" list if not? I've got it on my todo list. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 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]
Re: [PATCH] NetWare Support for OpenSSL 0.9.8
Has anyone had a chance to look at this patch yet? Is it on anyone's "to do" list if not? Thanks for any feedback. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> [EMAIL PROTECTED] 6/27/2003 11:35:43 AM >>> This patch adds support for the NetWare OS to OpenSSL 0.9.8. After applying this patch, the instructions for building for NetWare can be found in the "install.nw" file in the root directory. This patch attempts to minimize impact on other platforms through the judicious use of the preprocessor guard "OPENSSL_SYS_NETWARE". It does introduce one new general purpose function "ERR_free_state_table" which we found useful when cleaning up threads. I have applied the patch to the latest 0.9.8 development snapshots and built for both NetWare and Windows. The test suite runs correctly on both platforms with the patch applied. (Thank you for the changes made to get the Windows build working correctly. Everything now builds for Windows with the minor caveat that I still had to remove one reference to "ENGINE_load_gmp" from util\libeay.num to get the shared libraries to link.) This patch is almost identical to the patch submitted against OpenSSL 0.9.7 on June 11. There are a few minor differences. Has anyone had a chance to look at the 0.9.7 patch and consider if it can also be applied in that branch of the development tree? (For your reference I have also attached the 0.9.7 patch if you desire to look at it again.) Thank you for your consideration of this work. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Compiling/Linking OpenSSL 0.9.8 for Windows
rror LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' As near as I can tell even though these functions exist in the public header files, none of them are defined in the actual code. The easiest way to work around this problem is to remove the references to the functions in util\libeay.num. This results in a number of warnings, but the code compiles, links and tests properly. I am not sure what the "correct" solution is. Hope this helps. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare Support for OpenSSL 0.9.7
oad_aep LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_atalla LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_chil LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_cswift LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_gmp LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_nuron LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_sureware LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_ubsec LIBEAY32.def : error LNK2001: unresolved external symbol STORE_Directory LIBEAY32.def : error LNK2001: unresolved external symbol STORE_File LIBEAY32.def : error LNK2001: unresolved external symbol STORE_ctrl LIBEAY32.def : error LNK2001: unresolved external symbol STORE_method_get_cleanup_function LIBEAY32.def : error LNK2001: unresolved external symbol STORE_method_get_initialise_function LIBEAY32.def : error LNK2001: unresolved external symbol STORE_method_get_modify_function LIBEAY32.def : error LNK2001: unresolved external symbol STORE_method_set_cleanup_function LIBEAY32.def : error LNK2001: unresolved external symbol STORE_method_set_initialise_function LIBEAY32.def : error LNK2001: unresolved external symbol STORE_method_set_modify_function LIBEAY32.def : error LNK2001: unresolved external symbol STORE_modify_arbitrary LIBEAY32.def : error LNK2001: unresolved external symbol STORE_modify_certificate LIBEAY32.def : error LNK2001: unresolved external symbol STORE_modify_crl LIBEAY32.def : error LNK2001: unresolved external symbol STORE_modify_number LIBEAY32.def : error LNK2001: unresolved external symbol STORE_modify_private_key LIBEAY32.def : error LNK2001: unresolved external symbol STORE_modify_public_key out32dll.dbg\libeay32.lib : fatal error LNK1120: 24 unresolved externals LINK : fatal error LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' so I finally quit. (I did have Windows static libraries at this point which pass the test suite.) The Windows build obviously isn't quite ready for prime time. :-) BTW, I also see the warning: Warning: STORE_ATTR_INFO_in_range does not have a number assigned when configuring the make files. Verdon >>> Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> 6/11/2003 4:45:24 PM >>> In message <[EMAIL PROTECTED]> on Wed, 11 Jun 2003 10:43:03 -0600, "Verdon Walker" <[EMAIL PROTECTED]> said: VWalker> I have also applied the patch to the latest 0.9.8 development VWalker> snapshot. It applies (with the exception of changes to VWalker> "hw_aep.c" which does not exist in the 0.9.8 tree), crypto/engine/hw_aep.c has been moved and is called engines/e_aep.c in 0.9.8-dev. VWalker> but I have not been able to build and test 0.9.8 yet because VWalker> the underlying snapshot will not build for Windows even VWalker> without the patch applied. (I did fix the problem with the VWalker> "store.h" header file, but I still am not building.) Please send me a log and I'll see what I can do. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 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]
Submitting a Patch
I have a patch ready to be submitted which will add NetWare support to OpenSSL 0.9.7. I have tested it with the latest snapshots and everything is looking good. I would like the patch to go into the 0.9.8 branch as well as the 0.9.7 branch, but when I downloaded the latest snapshot (6-10) for 0.9.8 it doesn't compile for Windows (before applying my patch). How should I go about creating a patch file for 0.9.8? Are the snapshots normally stable? or do I just work with what is there even if it doesn't compile? or do I not need to worry about 0.9.8 yet? BTW, the code won't compile because it does not find the include file "openssl/store.h" which is referenced by "engine.h" Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Updated Patch for NetWare Support in OpenSSL 0.9.6i
No action was ever taken on this request. Is there something more I need to do? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com >>> [EMAIL PROTECTED] 3/14/2003 5:23:20 PM >>> This patch adds support for static OpenSSL libraries that will run on the NetWare 5, NetWare 5.1 and NetWare 6 platforms. This support has been added to the 0.9.6i source and has been tested on the platforms listed. Shared library support (nlm) is not supported at this time. If the development team would be so kind as to replace the "netwarepatch-0.9.6h.diff.gz" file on the Contributions page with this patch, we would be very appreciative. We are working to submit a patch to add NetWare support to the development branch in 0.9.7, but this will give NetWare developers an option until that occurs. Note: Since this submission is from the USA, we have CC'd the appropriate US government office as outlined in the Readme. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Thread Question
I knew I had not explained myself well enough given your last response. I did not mean to attempt to abort the "current chunck", but rather to be able to read the cancel between chunks so I could do just what you suggest. Of course, the definition of "current chunk" is part of my problem. I was thinking of the fact that when I do an SSL_write on a very large buffer, OpenSSL breaks it up into 16k pieces. Can I somehow do a read in between writing those 16k pieces or do I have to step back and do it between just between the "chunks" I sent to OpenSSL through SSL_write? BTW, we are using non-blocking sockets so I could clearly read from the socket between socket writes, but if I SSL_read from the socket during a long SSL_write operation, I am asking for trouble (with the internal state) so I don't think I can do the synchronization down at the BIO level unless I am still missing a big piece of the puzzle. Thanks again for taking the time to respond to my questions. Your feedback is very helpful. I apologize that this discussion has taken on a "user" tone rather than a "developer" tone. That was not my original intent. Verdon >>> [EMAIL PROTECTED] 3/19/2003 5:54:04 PM >>> On Wed, 19 Mar 2003 16:53:32 -0700, Verdon Walker wrote: >First, thank you for your responses. I appreciate the feedback, but >I don't think I understand the points you are making in your last >email. >Perhaps, I did not explain myself well enough, but the idea of >allowing >long operations to be cancelled is hardly rare. Suppose for example, >you >want to search for a friend in the phone book. Whatever criteria you >specify you are going to want to stop excessive search results from >continuing once you have found the person you are looking for. >Supporting that in a clear text mode, but not in an SSL mode doesn't >make sense. You try to send 2Mb but then interrupt it. 1,503,257 bytes have been sent. Now what do you do? Do you go back retrospectively and say, "oh, I'm 39 bytes into a 512 byte protocol structure, I'll have to send 473 bytes to recover synchronization so I can start another block? I have written code layered on top of TCP for more than 16 years and I've never seen anything like this. Much more common is to stop feeding data to the socket by not sending additional chunks to the sender. In other words, you finish the current 'chunk' and don't send anymore chunks. This requires no special support from the socket code and will work fine with OpenSSL. >It would seem that the SSL structure could be shared between reads >and >writes if we could guarantee that they didn't use the same members >of >the structure. Does anyone know which members are shared between both >reads and writes. I know the "rwstate" is, but I'm not sure what >else. You are barking up the wrong tree. Sending on an SSL link can require receiving from the underlying TCP stream and vice versa. You can't easily make them independent and I don't think you should want to. If you must, you can write your own send and receive functions that acquire a single lock while they're waiting for the send or receive to be possible using non-blocking sockets or BIO pairs. DS __ 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: Thread Question
First, thank you for your responses. I appreciate the feedback, but I don't think I understand the points you are making in your last email. Perhaps, I did not explain myself well enough, but the idea of allowing long operations to be cancelled is hardly rare. Suppose for example, you want to search for a friend in the phone book. Whatever criteria you specify you are going to want to stop excessive search results from continuing once you have found the person you are looking for. Supporting that in a clear text mode, but not in an SSL mode doesn't make sense. It would seem that the SSL structure could be shared between reads and writes if we could guarantee that they didn't use the same members of the structure. Does anyone know which members are shared between both reads and writes. I know the "rwstate" is, but I'm not sure what else. Verdon >>> [EMAIL PROTECTED] 3/19/2003 12:41:37 PM >>> OpenSSL doesn't support cancelable operations simply because it is extremely rare that someone would want to use them. You may implement your own buffering with asynchronous semantics if you wish. You could also use OpenSSL BIO pairs for this purpose. OpenSSL just can't give you the same semantics TCP does without being integrated into the operating system. DS __ 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: Thread Question
While that (not simultaneously accessing the same structure from different threads) is certainly understandable, it is often the case that an SSL implementation will mimic a socket implementation. In fact, the clear socket implementation is always a candidate for SSL work and it is perfectly acceptable to have separate threads reading and writing from/to a socket. The socket itself will handle the contention this may cause. I am getting "beat up" because OpenSSL doesn't follow the "socket model" which seems unreasonable to some of my coworkers trying to use SSL sockets in more or less the same fashion as clear sockets (at least with the same basic architecture). I know from looking in the email archives that this issue has come up before so we are not the only ones struggling with it. The suggested solution was to create a mutex and use the ex_data for the SSL structure to tie it to the connection and then mutex read/write access. I am willing to do that, but even that is not terribly straight forward. Consider: We have one thread wanting to write a large amount of data (say 2 Meg). OpenSSL will break that data up into 16k chunks, SSLize them and write each separately. During the process, it is using the "rwstate" in the SSL structure to indicate the status of the write operation. How do I then process a "cancel" instruction that I might receive from an impatient client who decides they don't want or need to see all 2 Meg of data? Is it safe to do a read operation between the writes of each 16k chunk or do I need to wait until all 2 Meg have been written? With clear sockets, a separate thread for reading and writing works very well to handle this. With OpenSSL, the state of the write can easily be stomped on by reading the "cancel". Verdon >>> [EMAIL PROTECTED] 3/18/2003 7:10:23 PM >>> On Mon, 17 Mar 2003 11:26:46 -0700, Verdon Walker wrote: >I know from looking in the archives that this question has been >asked >before, but I am wondering if anything has been done in the 0.9.7 >branch >to address it. >We have an application that uses separate threads for its readers and >writers. Currently, the threads can stomp on each others state since >they are using the same SSL structure. In particular, the "rwstate" >flag >can get trashed and confuse one thread or the other about what is >happening. I know that OpenSSL does not support this in the 0.9.6 >branch, but was anything done to address it in 0.9.7 or is anything >planned in 0.9.8? No. Most libraries are thread safe in the sense that they work fine so long as two threads don't try to modify the same structure at the same time. Trying to change this generally makes things worse. DS __ 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]
Thread Question
I know from looking in the archives that this question has been asked before, but I am wondering if anything has been done in the 0.9.7 branch to address it. We have an application that uses separate threads for its readers and writers. Currently, the threads can stomp on each others state since they are using the same SSL structure. In particular, the "rwstate" flag can get trashed and confuse one thread or the other about what is happening. I know that OpenSSL does not support this in the 0.9.6 branch, but was anything done to address it in 0.9.7 or is anything planned in 0.9.8? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Bug in SSL_get_ciphers()
The code for SSL_get_ciphers has a flaw. If "s" is null, it will crash
on the "else if" statement.
STACK_OF(SSL_CIPHER) *SSL_get_ciphers(SSL *s)
{
if ((s != NULL) && (s->cipher_list != NULL))
{
return(s->cipher_list);
}
else if ((s->ctx != NULL) &&
(s->ctx->cipher_list != NULL))
{
return(s->ctx->cipher_list);
}
return(NULL);
}
Note that ssl_get_ciphers_by_id() fixes the defect by introducing
another check of "(s != NULL)" in the "else if" statement. The code for
SSL_get_ciphers() should do the same.
Verdon Walker
(801) 861-2633
[EMAIL PROTECTED]
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #415] [PATCH] NetWare support for OpenSSL 0.9.6h
This does not seem to have shown up in the contributions area. Are we still waiting for an update or did something go wrong? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> "Richard Levitte via RT" <[EMAIL PROTECTED]> 12/23/2002 4:49:22 AM >>> I just added the patch to http://www.openssl.org/contrib/. It should become visible within the next hour. That resolves this ticket. [[EMAIL PROTECTED] - Fri Dec 20 22:17:58 2002]: > This patch adds support for static OpenSSL libraries that will run on >the NetWare 5, NetWare 5.1 and NetWare 6 platforms. This support >has been added to the 0.9.6h source and has been tested on the >platforms listed. Shared library support (nlm) is not supported at >this time. > > We understand that 0.9.6h was the last released version on the 0.9.6 >branch so developers who want NetWare support will need to apply >this patch manually to OpenSSL 0.9.6h. We do plan to move these >changes forward into the 0.9.7 branch, but have not done so yet and >if some enterprising developer beats us to the task we will not be >offended. :-) > > Note: Since this submission is from the USA, we have CC'd the > appropriate US government office as outlined in the Readme. > > > Verdon Walker > (801) 861-2633 > [EMAIL PROTECTED] > Novell, Inc., the leading provider of Net business solutions > http://www.novell.com > > -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #415] [PATCH] NetWare support for OpenSSL 0.9.6h
This patch adds support for static OpenSSL libraries that will run on the NetWare 5, NetWare 5.1 and NetWare 6 platforms. This support has been added to the 0.9.6h source and has been tested on the platforms listed. Shared library support (nlm) is not supported at this time. We understand that 0.9.6h was the last released version on the 0.9.6 branch so developers who want NetWare support will need to apply this patch manually to OpenSSL 0.9.6h. We do plan to move these changes forward into the 0.9.7 branch, but have not done so yet and if some enterprising developer beats us to the task we will not be offended. :-) Note: Since this submission is from the USA, we have CC'd the appropriate US government office as outlined in the Readme. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] NetWare support for OpenSSL 0.9.6h
Would it be possible to have this patch added to the OpenSSL Contributions area until we are able to get it merged into the 9.7 development branch? Thanks. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] 12/13/2002 9:48:49 PM >>> This patch adds support for static OpenSSL libraries that will run on the NetWare 5, NetWare 5.1 and NetWare 6 platforms. This support has been added to the 0.9.6h source and has been tested on the platforms listed. Shared library support (nlm) is not supported at this time. We understand that 0.9.6h was the last released version on the 0.9.6 branch so developers who want NetWare support will need to apply this patch manually to OpenSSL 0.9.6h. We do plan to move these changes forward into the 0.9.7 branch, but have not done so yet and if some enterprising developer beats us to the task we will not be offended. :-) Note: Since this submission is from the USA, we have CC'd the appropriate US government office as outlined in the Readme. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Status of 0.9.6h?
What is the status of the 0.9.6h defect release? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
uni2asc & asc2uni naming conflict
One of the projects here that is using OpenSSL is running into a naming conflict between OpenSSL and other libraries because of the uni2asc() routine in the crypto\pkcs12 subdirectory. What is the possibility of renaming uni2asc() to PKCS12_uni2asc() and asc2uni() to PKCS12_asc2uni() to not only avoid this naming conflict, but also to make these two function names more consistent with the other functions defined in pkcs12.h? Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PATCH: Elimination of unused 10k stack variable
It is always painful to admit when you are wrong, but hopefully I will save at least some face by doing it now. You are correct that the static buffer is used and dynamic buffer is only used when the static buffer runs out of space. In my defense, I did post an inquiry about the code before submitting a patch. In any case, my problem is a real one. I did crash because of using too much stack (not a stack "overrun" as I misstated). I can increase the size of the application stack in this particular case, but that seems like a bandaid since I can not guarantee the stack size of every application that might call into this library. A 10240 byte stack variable does seems rather large in any case so I respectfully withdraw my patch from consideration and ask instead that a change be made to make the buffer allocated on the stack a more reasonable size - say 1 or 2k. Thanks for your feedback and for correcting my misunderstanding. Verdon >>> [EMAIL PROTECTED] 05/09/02 12:15PM >>> In message <[EMAIL PROTECTED]> on Wed, 08 May 2002 17:31:41 -0600, "Verdon Walker" <[EMAIL PROTECTED]> said: VWalker> This patch fixes the routine BIO_vprintf in VWalker> crypto\bio\b_print.c so that no longer allocates a 10k buffer VWalker> on the stack that is never really used. I just looked at the code, and I have a hard time seeing why the stack-allocated buffer would never be used. Please note that any heap allocation will be made only when *currlen gets larger than or equal to *maxlen. When the static buffer is passed, it's size (10240) is also passed, so allocation of the dynamic buffer will only happen when that functionality is desired (by passing the appropriate pointer) and the calling function is about to overflow the static buffer. At least, this is what I can conclude by looking at the code. If you're of a different opinion on how it works, please show me. I entirely agree with the move of the assert() in doapr_outch(), and will apply that part immediately. I'll think about the rest. -- 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]
Question about b_print.c
I ran into a problem with a stack overflow that has me looking at the
crypto\bio\b_print.c code and wondering a few things. Consider the
following routine (note especially the MS_STATIC variable):
int BIO_vprintf (BIO *bio, const char *format, va_list args)
{
int ret;
size_t retlen;
MS_STATIC char hugebuf[1024*10];
char *hugebufp = hugebuf;
size_t hugebufsize = sizeof(hugebuf);
char *dynbuf = NULL;
int ignored;
dynbuf = NULL;
CRYPTO_push_info("doapr()");
_dopr(&hugebufp, &dynbuf, &hugebufsize,
&retlen, &ignored, format, args);
if (dynbuf)
{
ret=BIO_write(bio, dynbuf, (int)retlen);
OPENSSL_free(dynbuf);
}
else
{
ret=BIO_write(bio, hugebuf, (int)retlen);
}
CRYPTO_pop_info();
return(ret);
}
On a non-windows platform, there is a 10k buffer (hugebuf) being
allocated on the stack. That seems excessive and is causing me a stack
overrun. It seems even more excessive when looking at how it is used. It
is passed to _dopr and then to doapr_outch which is defined as follows:
static void
doapr_outch(
char **sbuffer,
char **buffer,
size_t *currlen,
size_t *maxlen,
int c)
{
/* If we haven't at least one buffer, someone has doe a big booboo
*/
assert(*sbuffer != NULL || buffer != NULL);
if (buffer) {
while (*currlen >= *maxlen) {
if (*buffer == NULL) {
assert(*sbuffer != NULL);
if (*maxlen == 0)
*maxlen = 1024;
*buffer = OPENSSL_malloc(*maxlen);
if (*currlen > 0)
memcpy(*buffer, *sbuffer, *currlen);
*sbuffer = NULL;
} else {
*maxlen += 1024;
*buffer = OPENSSL_realloc(*buffer, *maxlen);
}
}
/* What to do if *buffer is NULL? */
assert(*sbuffer != NULL || *buffer != NULL);
}
if (*currlen < *maxlen) {
if (*sbuffer)
(*sbuffer)[(*currlen)++] = (char)c;
else
(*buffer)[(*currlen)++] = (char)c;
}
return;
}
doapr_outch doesn't even use the static buffer if a dynamic buffer is
available so the 10k stack variable is completely unused in this code.
OK, the static buffer can be used in the memcpy, but that code isn't
used since *currlen will be 0 the first time we are called. The second
assert in doapr_outch prevents us from passing a pointer to a NULL
static buffer to _dopr but that assert seems to protect for code that is
never used (i.e. memcpy).
Bottom line, allocating an unused 10k stack variable seems like a bad
idea. I would remove the second assert in doapr_outch and pass a pointer
to a NULL static buffer to _dopr from BIO_vprintf if it were me. At the
very least the static buffer can be very minimal in size.
Can this change be made? Do I need to submit a patch to do it? Or am I
missing something?
Verdon Walker
(801) 861-2633
[EMAIL PROTECTED]
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
64 bit support
What is the status of support in OpenSSL for 64 bit architectures? We are compiling our code for an Itanium box and are wondering how much change may be required to get OpenSSL running as well. Thanks for your feedback. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of Net business solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Error Stack Question
We ran into a small piece of code in ssl_rsa.c that is confusing us. In SSL_CTX_use_certificate_chain_file(), the following code fragment exists: ret=SSL_CTX_use_certificate(ctx,x);if (ERR_peek_error() != 0) ret = 0; /* Key/certificate mismatch doesn't imply ret==0 ... */if (ret)... Isn't this a little strange to ignore the return code of the function called and instead peek at the error stack? There is certainly no guarantee that any errors on the stack are from the call to use_certificate and even so, why check the stack rather than the return code. This looks like a hack to me. Is there a specific reason it is needed? Thanks for any help. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
Postal Address for OpenSSL Group
Is there an official postal address for the OpenSSL group? We are filing some paperwork related to our use of OpenSSL and it requires an address. What would a person list? Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
Re: Out of the office
Can Tina please be dropped from the developer list until January 8th to eliminate this reoccuring email? Some with group rights, please help! Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com>>> [EMAIL PROTECTED] 01/02/02 04:55PM >>>I am on vacation till January 8th. If an issue can not wait till I return, please contact Rob Currey at [EMAIL PROTECTED] orNate Amsden at [EMAIL PROTECTED]For support questions, contact [EMAIL PROTECTED]For sales questions, contact [EMAIL PROTECTED]Regards,Tina Anderson__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL for Netware
We have ported OpenSSL to NetWare and are willing to submit that code to the source base. In fact, a couple of months ago a coworker submitted the following email: — I have a NetWare 5x port of OpenSSL. I completed the work a few months ago using the 0.9.6a code base. I would like to contribute the work back to the OpenSSL project but I'm not sure what is the best method to do this. In doing the port, I created a NetWare directory for platform specific files similar to the VMS, MacOS, and MS ports. The README indicates patches should be submitted using "diff -u" which I can do if this is the best way. Let me know if you would like the work and how you would like it submitted. I realize the 0.9.6a code base isn't the latest and I'm willing to update to the latest (0.9.6b?) before submitting the port. David Ward — He received no response. The big question is: if we submit a patch to OpenSSL to add NetWare support, will it be accepted? Is anyone else interested in this work? Thanks for your interest. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com >>> [EMAIL PROTECTED] 12/05/01 12:30AM >>> [Yaniv Alamaru] Hi,I am interested in a porting of open ssl for NetWare. My company works on asystem which is composed of several components on different machines whichhas to talk to each other in a secure way and open ssl is the solution forus. The system can work on Windows, Solaris and Netware platforms but futuredevelopment will enable us to support other platforms as well.The open ssl works on windows and Solaris but I did not started yet onporting the open ssl for Netware. If you have a project ready forcompilation (Like a code warrior project) or a static library or an nlm,please send it to me.thanks in advance Yaniv AlamaruSoftware EngineerCamelot IT LTD.
Re: OpenSSL for Novell NetWare
Yosi, We have ported OpenSSL to run on NetWare. I just spoke to the engineer who did the initial work and he will be packaging his work up for submission. The big question is: Are other people interested in support for NetWare? In particular, is the OpenSSL development team interested in seeing this work submitted as a patch against the OpenSSL code or should it just be passed along to specific individuals, like Yosi, who find a need for it? BTW, the current solution is a static library, not an nlm. I am working on an nlm solution, but it is too early in the development cycle to release that work for general consumption. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com>>> [EMAIL PROTECTED] 09/02/01 01:40PM >>>Hi,I want to compile openssl for Novell NetWare. Was this done before? If so, can anyone givedetailed instructions how to do it?If not, can you give general ideas of what should be done? How should I approach theporting of openssl to NetWare?Sincerely,Yosi
Re: Delivering a Single Library
Did you modify the configuration scripts to set up the single library or did you just edit the makefiles directly? That is the issue I am looking into now. (If you have anything you want to share, we'd love to see it.) Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com>>> [EMAIL PROTECTED] 07/09/01 08:49PM >>>Of all the gin joints in all the towns in all the world, Richard Levitte - VMS Whackerhad to walk into mine and say:> From: "Verdon Walker" <[EMAIL PROTECTED]>> > VWalker> We would like to deliver one library to our customers instead> VWalker> of separate libraries for cryptography (libeay) and SSL> VWalker> (ssleay). Has anyone done the work to support this already?> VWalker> If not, can anyone think of any problems in doing it? Or any> VWalker> reasons not to do it?> > I haven't heard of anyone doing that, but I can't see the harm if you> do it.We ship a single "libopenssl.so" to get around some shared-libraryissues (symbol conflicts between netscape's LDAP library and OpenSSL, ifI recall correctly). As a side effect, it also means that people runningour code get *our* version of the libraries, and not whatever theyhappen to have installed in /usr/lib :-)The .a's are just .a's; there's no reason why they couldn't be combinedinto a single .a. There aren't any filename conflicts, for example.-- Harald Koch <[EMAIL PROTECTED]>"It takes a child to raze a village." -Michael T. Fry__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Delivering a Single Library
We would like to deliver one library to our customers instead of separate libraries for cryptography (libeay) and SSL (ssleay). Has anyone done the work to support this already? If not, can anyone think of any problems in doing it? Or any reasons not to do it? Thanks for your help. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
[PATCH] Digest Processing Always using EVP layer & HMACProcessing
OOPS - I forgot to attach the patch!!! This is a resend of patches submitted against 0.9.6a that we had some dialog on last week. This patch is against the current development build openssl-snap-20010503. Note that the submission is from the USA and is CC'd to [EMAIL PROTECTED] even though it does not change any cryptographic code, only the functions that call cryptographic routines. The patch does the following: We are currently modifying OpenSSL to use a different crypto lib (for license and export reasons). One thing I have done to help reduce the entry points into our code is replace all calls directly to digest functions (MD5_Init, SHA1_Update, etc.) to always use the EVP layer. I think this is a useful cleanup item to be patched into the openssl source so I am submitting this patch. I replaced all direct references to digest functions in the ssl directory to call EVP functions. I believe that I also replaced all calls in the crypto and apps code. I also removed any references to the md5.h, sha.h, etc. header files in the sll directory. The patch also addresses this issue: Basically, in tls1_P_hash() (in ssl/t1_enc.c), the assumption is made that an HMAC_CTX can be used multiple times by simply memcpy'ing it into a temporary structure. This works if the context is a complete representation of the entire state of the HMAC. It may not work if the ctx has pointers or references to additional information that is not copied by this process (as is the case with the crypto lib we are using). This problem is fairly simple to fix in this case because the temporary context can simply be computed along side the other rather than memcpy to it. (This may be slightly less efficient, but is certainly a cleaner implementation.) This patch also includes a couple of fixes to code that use HMAC, but never call HMAC_cleanup. This is critical, again, if the HMAC_CTX contains any references to other objects that must be cleaned up. The code passes all tests in test.bat. It was built on WindowsNT but should be portable to all platforms. Any questions, comments or concerns, please contact me. Thanks. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com hmacdigest.patch.20010503
[PATCH] Digest Processing Always using EVP layer & HMACProcessing
This is a resend of patches submitted against 0.9.6a that we had some dialog on last week. This patch is against the current development build openssl-snap-20010503. Note that the submission is from the USA and is CC'd to [EMAIL PROTECTED] even though it does not change any cryptographic code, only the functions that call cryptographic routines. The patch does the following: We are currently modifying OpenSSL to use a different crypto lib (for license and export reasons). One thing I have done to help reduce the entry points into our code is replace all calls directly to digest functions (MD5_Init, SHA1_Update, etc.) to always use the EVP layer. I think this is a useful cleanup item to be patched into the openssl source so I am submitting this patch. I replaced all direct references to digest functions in the ssl directory to call EVP functions. I believe that I also replaced all calls in the crypto and apps code. I also removed any references to the md5.h, sha.h, etc. header files in the sll directory. The patch also addresses this issue: Basically, in tls1_P_hash() (in ssl/t1_enc.c), the assumption is made that an HMAC_CTX can be used multiple times by simply memcpy'ing it into a temporary structure. This works if the context is a complete representation of the entire state of the HMAC. It may not work if the ctx has pointers or references to additional information that is not copied by this process (as is the case with the crypto lib we are using). This problem is fairly simple to fix in this case because the temporary context can simply be computed along side the other rather than memcpy to it. (This may be slightly less efficient, but is certainly a cleaner implementation.) This patch also includes a couple of fixes to code that use HMAC, but never call HMAC_cleanup. This is critical, again, if the HMAC_CTX contains any references to other objects that must be cleaned up. The code passes all tests in test.bat. It was built on WindowsNT but should be portable to all platforms. Any questions, comments or concerns, please contact me. Thanks. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
Re: [PATCH] HMAC Processing
While I agree that adding some sort of EVP_MD_CTX_copy() for HMAC's would be much better than a memcpy(), it would not solve our problem. Our crypto library does not support any type of copy operation for contexts so we would still have a problem. And yes, we have seen, that Digest contexts are copied which also causes us some problems. For example, we have had to add code to keep multiple copies of the handshake digest context since we have no way to copy it. On the separate issue of cleaning up HMAC's in HMAC_Final(), there does appear to be a problem doing this (at least in the code in t1_enc.c). There seem to be two different flavors of HMAC_Init(). You can call HMAC_Init() with a key for a full initialization or you can call it with a NULL key and it will reuse the key from the previous Init. I believe this is why a separate cleanup routine was created so that you can specify the difference between being really done and just ready for a value but still planning to do some more processing. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com >>> [EMAIL PROTECTED] 04/28/01 06:41AM >>>I'd missed this comment earlier, hence the reason I didn't reply...> Verdon Walker wrote:> > > Basically, in tls1_P_hash() (in ssl/t1_enc.c), the assumption is made> that an HMAC_CTX can be used multiple times by simply memcpy'ing it> into a temporary structure. This works if the context is a complete> representation of the entire state of the HMAC. It may not work if the> ctx has pointers or references to additional information that is not> copied by this process (as is the case with the crypto lib we are> using). This problem is fairly simple to fix in this case because the> temporary context can simply be computed along side the other rather> than memcpy to it. (This may be slightly less efficient, but is> certainly a cleaner implementation.)> Well there are some assumptions of this sort already in places forEVP_MD_CTX and EVP_CIPHER_CTX. They occasionally call EVP_MD_CTX_copy()which just mempcpy's the buffer.Again this is OK for internal stuff but some other digest forms wontwork.What is really needed is an additional function in EVP_MD which can beset to provide an implementation specific copy operation.As far as HMAC is concerned we could either EVP_MD_CTX_copy() therelevant operations or have some kind of HMAC 'method' where the wholeoperation can be placed under application control.> This patch also includes a couple of fixes to code that use HMAC, but> never call HMAC_cleanup. This is critical, again, if the HMAC_CTX> contains any references to other objects that must be cleaned up.> Hmmm... is there a problem with cleaning up in HMAC_Final()?Steve.-- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/Core developer of the OpenSSL project: http://www.openssl.org/Business Email: [EMAIL PROTECTED] PGP key: via homepage.__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Re: Engine vs. Crypto Lib Question
Thanks for the feedback. I really appreciate it. We hope to be active, participating members of the OpenSSL community and this type of information really helps. It would appear that I had some misunderstandings about the Engine interface. Thanks for clearing them up. At this point, I think we will continue on the path we are on which, BTW, is well past the point of coding around the edges of OpenSSL (hard core as you would say :-). Since we are attempting primarily to hook our library in at the EVP layer, I do think much of what we find we need to do may be of use to your Engine development if that is the same level you are targetting for interfacing with SSL/TLS. (It should also simplify our task should we decide later to convert to the Engine interface.) At this point, I will start taking a look at the development builds in an effort to push back any changes we are making (EVP implementation of digests, ciphers, etc.) in that context and hope that it can be of benefit to all of us. Cheers. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com >>> [EMAIL PROTECTED] 04/26/01 05:30PM >>>Hi there,If you're on the commit mail list you'll probably be aware why I haven't had achance to answer your posts until now. :-) Thanks for the contributions w.r.t.standardising the use of EVP ... it's the kind of thing that needs doing andsoon (see below #3) it will be even more important. Like Steve said, if youcould work your patch into a recent snapshot of 0.9.7-dev, that would make lifeeasier for us to review it and add it.On Thu, 26 Apr 2001, Verdon Walker wrote:> As I have mentioned before, we are currently producing an OpenSSL solution> that uses our own cryptography library for ALL cryptographic functionality> (instead of using libeay for those functions). We have elected to actually> replace the underlying crypto functions in libeay with calls to our own> library (at the EVP level wherever possible) instead of attempting to use the> ENGINE interface. We are doing this for various reasons and I wanted to run> them by you to see if our thinking is sound (or if we have missed something):Sure thing. The ENGINE stuff is moving quite swiftly - you'll probably see anumber of fairly major improvements (and necessarily, changes) in the underlyingcode and the API before 0.9.7 approaches. On the one hand, this may provide youwith something useful, on the other hand it may also scare you off until itsettles down a bit. YMMV.> 1 - It appears that Engine is meant to provide support for alternate solutions> (primarily hardware), but will fall back to the libeay software solution if no> other engines exist. We must use our library for all cryptography. It is not> optional.Um, no. It is easy to code an ENGINE to fallback to another ENGINE in the eventof ENGINE-specific errors, together with whatever retry logic is required.However, if an ENGINE doesn't support handling failed operations by falling backto something else, then any failed operation *stays* failed. If you simply wantto ensure that the 'openssl' ENGINE isn't available or that its role is replaced- edit the 'engine_internal_check()' function in engine_list.c and replace thecall to ENGINE_openssl() with the ENGINE you'd like to replace it with.> 2 - Engine does not support cryptography that is not also supported through> the standard software interface. Richard Levitte just started a thread on this> topic (Disabling algorithms) which is really what got me thinking about this> again. In any case, if we disable the current software solutions, it would> appear that we also disable any ability to provide the solutions through the> engine. See #1 to understand why this is not acceptable for us.Again, I don't think this is true (if I understood you correctly). See theanswer to #1 to understand why. :-)> 3 - Engine does not currently support all cryptographic functionality. Most> notable would be symmetric ciphers, but we also need to use our library for> RAND and other functions that may not be supported either.RAND is supported through the ENGINE interface, and once again you couldhard-code it in as the startup default if you wish. Symmetric cipher support iscoming - I've already discussed with a couple of the others about how this canbe done and some of the current changes are to better facilitate this. Ienvisage that EVP_CIPHER and EVP_MD support will be in the ENGINE code soon. Theone thing it won't do due to far more fundamental difficulties is deal withopaque (hardware-managed) symmetric keys. That doesn't seem to be an issue forwhat you're doing, but it may be to someone else out there lurking and watchingthis.> 4 - Engine is still in early development and may not be a
Re: [PATCH] Digest Processing Always using EVP layer +Addendumto [PATCH]
Thanks for the feedback. Both of these suggestions seem so obvious that I now wonder why I didn't think of them. These does lead to one obvious question: Should I do the work and resubmit my patches for HMAC processing and doing all digesting through the EVP layer against 0.9.7 or has someone already done this work? Thanks again. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com >>> [EMAIL PROTECTED] 04/26/01 04:48PM >>>> Verdon Walker wrote:> > > I appreciate your feedback. In general, is this type of patch useful> for me to submit? You mentioned that some of the work is already done> in 0.9.7 so am I submitting redundant changes? What criteria should I> use when determining what patches to submit? We are making a number of> changes to OpenSSL in order to replace the standard crypto lib, but I> only want to submit changes that are generally useful to whole OpenSSL> community. Any guidelines would be appreciated. Thanks.> Well in general you should supply patches against the currentdevelopment version of OpenSSL. The actual changes from 0.9.6a and0.9.7-dev are considerable and whole sections of the library have beenrewritten.In general its a good idea to mention any changes or areas you thinkneed changing in openssl-dev first. Someone may be already working onthe changes anyway and not committed them yet.Steve.-- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/Core developer of the OpenSSL project: http://www.openssl.org/Business Email: [EMAIL PROTECTED] PGP key: via homepage.__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Engine vs. Crypto Lib Question
As I have mentioned before, we are currently producing an OpenSSL solution that uses our own cryptography library for ALL cryptographic functionality (instead of using libeay for those functions). We have elected to actually replace the underlying crypto functions in libeay with calls to our own library (at the EVP level wherever possible) instead of attempting to use the ENGINE interface. We are doing this for various reasons and I wanted to run them by you to see if our thinking is sound (or if we have missed something): 1 - It appears that Engine is meant to provide support for alternate solutions (primarily hardware), but will fall back to the libeay software solution if no other engines exist. We must use our library for all cryptography. It is not optional. 2 - Engine does not support cryptography that is not also supported through the standard software interface. Richard Levitte just started a thread on this topic (Disabling algorithms) which is really what got me thinking about this again. In any case, if we disable the current software solutions, it would appear that we also disable any ability to provide the solutions through the engine. See #1 to understand why this is not acceptable for us. 3 - Engine does not currently support all cryptographic functionality. Most notable would be symmetric ciphers, but we also need to use our library for RAND and other functions that may not be supported either. 4 - Engine is still in early development and may not be as stable as the standard code base. 5 - We have not been able to find much documentation about how to use the Engine interface. This is probably not an exhaustive list, but is sufficient for making the decision that Engine is not an option for providing the solution we want at this time. Am I incorrect in any of my assumptions or conclusions? Are there other considerations I have missed that would make the Engine more palatable for what we are doing? You time and consideration of these questions is greatly appreciated. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
Re: [PATCH] Digest Processing Always using EVP layer +Addendum to [PATCH]
I wholeheartedly agree on the static buffer in EVP_Digest(). I didn't want to add it and it doesn't look like anyone uses it, but I added it to keep the functionality consistent. I did discover that I missed one place where digests are still called directly in the RAND code. (We are using our own library for rand functions so I overlooked it.) See the attached patch for a fix to use the EVP layer in rand. (I also included a copy of rand_lcl.h since the patch output makes it difficult to see what changed in that file.) I did take the liberty to swap the arguments to MD_Final so that the context comes first (matches EVP order and seems more consistent with other calls). I appreciate your feedback. In general, is this type of patch useful for me to submit? You mentioned that some of the work is already done in 0.9.7 so am I submitting redundant changes? What criteria should I use when determining what patches to submit? We are making a number of changes to OpenSSL in order to replace the standard crypto lib, but I only want to submit changes that are generally useful to whole OpenSSL community. Any guidelines would be appreciated. Thanks. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com >>> [EMAIL PROTECTED] 04/25/01 07:03PM >>>> Verdon Walker wrote:> > We are currently modifying OpenSSL to use a different crypto lib (for> license and export reasons). One thing I have done to help reduce the> entry points into our code is replace all calls directly to digest> functions (MD5_Init, SHA1_Update, etc.) to always use the EVP layer. I> think this is a useful cleanup item to be patched into the openssl> source so I am submitting this patch.> > I created a new function called "EVP_Digest" to replace calls to MD5,> SHA1, etc. I replaced all direct references to digest functions in the> ssl directory to call EVP functions. I believe that I also replaced> all calls in the crypto and apps code. I also removed any references> to the md5.h, sha.h, etc. header files in the sll directory.> > This patch was built using a clean version of 0.9.6a. The code passes> all tests in test.bat. It was built on WindowsNT but should be> portable to all platforms.> > Note: The patch has been copied to [EMAIL PROTECTED] since it> orignates in the USA. The code changes are not in any cryptographic> functions only in the code calling the cryptographic functions.> > I hope that I have submitted this patch correctly. Please let me know> if there is anything more I need to do. I hope the diff is OK. I am> developing on Windows 2000 and my version of diff does not have a -u> option. I hope the slightly different format is OK.> > Any questions, comments or concerns, please contact me. Thanks.> I agree that the applications, and indeed the library should not makelow level digest calls and should use EVP. This kind of thing will beneeded when/if when digests get added to ENGINE anyway.There is already an EVP_Digest() function in OpenSSL 0.9.7-dev which hassimilar functionality, except it doesn't use the static buffer if md isNULL which isn't threadsafe anyway.Steve.-- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/Core developer of the OpenSSL project: http://www.openssl.org/Business Email: [EMAIL PROTECTED] PGP key: via homepage.__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED] digest.patch2 rand_lcl.h
[PATCH] Digest Processing Always using EVP layer
We are currently modifying OpenSSL to use a different crypto lib (for license and export reasons). One thing I have done to help reduce the entry points into our code is replace all calls directly to digest functions (MD5_Init, SHA1_Update, etc.) to always use the EVP layer. I think this is a useful cleanup item to be patched into the openssl source so I am submitting this patch. I created a new function called "EVP_Digest" to replace calls to MD5, SHA1, etc. I replaced all direct references to digest functions in the ssl directory to call EVP functions. I believe that I also replaced all calls in the crypto and apps code. I also removed any references to the md5.h, sha.h, etc. header files in the sll directory. This patch was built using a clean version of 0.9.6a. The code passes all tests in test.bat. It was built on WindowsNT but should be portable to all platforms. Note: The patch has been copied to [EMAIL PROTECTED] since it orignates in the USA. The code changes are not in any cryptographic functions only in the code calling the cryptographic functions. I hope that I have submitted this patch correctly. Please let me know if there is anything more I need to do. I hope the diff is OK. I am developing on Windows 2000 and my version of diff does not have a -u option. I hope the slightly different format is OK. Any questions, comments or concerns, please contact me. Thanks. PS What feedback should I expect when a Patch is submitted. I previously submitted a small Patch for HMAC processing and never saw anything. Am I doing something wrong or do I need to do something differently? Thanks for your help on these matters. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com digest.patch
How many times can handshake messages be digested?
We are incorporating a different crypto lib into OpenSSL and are running into a few problems because assumptions are made about how the crypto lib works. One problem we are running into is that EVP_MD_CTX_copy() is not supported by our crypto lib. We have no way to make a working copy of a current digest context so that we can finalize one and continue digesting in the other. Obviously, this produces a problem with the handshakes because we need to digest the handshake messages up to the first finished message, finalize it to compare results and then continue digesting until the second finished message. We basically have two choices: 1) ask our crypto provider to support digest context copies or 2) maintain multiple digest contexts for the different times when we need to finalize a digest value. We have chosen to follow path #2 which leads to a couple of questions: 1) Has anyone done this before and do you have a working implementation that we could reference? Or do you have any ideas about a preferred way to implement a change like this? 2) How many digest contexts need to be maintained to support the handshake? Certainly, there are at least two for the 2 finished messages, but I believe we need a third in case a CertificateVerify is sent. Do we need more than 3? Thanks, as always, for your insight and help. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
[PATCH] HMAC Processing
We are currently modifying OpenSSL to use a different crypto lib (for license and export reasons). In the process, we have discovered a few places where the SSL code depends on the way the crypto lib works. This patch addresses one of those issues. Basically, in tls1_P_hash() (in ssl/t1_enc.c), the assumption is made that an HMAC_CTX can be used multiple times by simply memcpy'ing it into a temporary structure. This works if the context is a complete representation of the entire state of the HMAC. It may not work if the ctx has pointers or references to additional information that is not copied by this process (as is the case with the crypto lib we are using). This problem is fairly simple to fix in this case because the temporary context can simply be computed along side the other rather than memcpy to it. (This may be slightly less efficient, but is certainly a cleaner implementation.) This patch also includes a couple of fixes to code that use HMAC, but never call HMAC_cleanup. This is critical, again, if the HMAC_CTX contains any references to other objects that must be cleaned up. Note that this patch has also been sent to: [EMAIL PROTECTED]. I hope that I have submitted this patch correctly. Please let me know if there is anything more I need to do. I hope the diff is OK. I am developing on Windows 2000 and my version of diff does not have a -u option. I hope the slightly different format is OK. Any questions, comments or concerns, please contact me. Thanks. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com diff.out
Re: Handshake Failure with some ciphers
Thank you for your response. I'm sorry to bother again, but I'm still not sure what I am doing wrong so can someone answer this question: What do I need on the server side to get "openssl s_client -cipher EDH-DSS-DES-CBC3-SHA" to handshake properly? (I assume that I don't need a certificate on the client side.) This is what I currently do on the server side: From the apps directory (this is Windows 2000), I run ..\out32dll\openssl s_server to just start up a default server (which I believe uses the default "server.pem" certificate file). On the client side, I run (from the out32dll directory) openssl s_client -cipher EDH-DSS-DES-CBC3-SHA and it doesn't handshake. What certificate file should I be using for this cipher designation? Does this work for everyone else? Thanks again for your help. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com >>> [EMAIL PROTECTED] 04/12/01 12:19PM >>>On Thu, Apr 12, 2001 at 11:18:25AM -0600, Verdon Walker wrote:> This is very true, but in the case I am testing both sides are running the exact same version of openssl.exe. (One side as the server and one as the client.) Certainly, the same version of openssl.exe should be supporting the same cipher suites, shouldn't it?From the "compiled in" point of view, yes.However: for a cipher to be usable, the cipher must be compiled in _and_the necessary certificates must be present. So for cipher with RSAauthentication, a RSA certificate must be present on the server side,for a cipher with DSA authentication, a DSA certificate must be presenton the server side. All DSA ciphers and some RSA ciphers (with EDH)also do need DH parameters. Openssl s_server has built in DH-parameters,so the last point cannot be your problem.Best regards, Lutz-- Lutz Jaenicke [EMAIL PROTECTED]BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Re: Handshake Failure with some ciphers
This is very true, but in the case I am testing both sides are running the exact same version of openssl.exe. (One side as the server and one as the client.) Certainly, the same version of openssl.exe should be supporting the same cipher suites, shouldn't it? BTW, I forgot to mention that this is a completely clean build of 0.9.6a. (I just downloaded it and built it yesterday.) Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com>>> [EMAIL PROTECTED] 04/12/01 11:12AM >>>> > I wrote a little batch file to check that I can handshake with ALL the ciphers that are output from an "openssl ciphers" command. (BTW, I am running on a Windows 2000 box with the latest 0.9.6a build.) Unfortunately, some of the ciphers do> not seem to work when passed in using an "openssl s_client -cipher XXX-XXX-XXX" command. (I am running a standard "openssl s_server" in another window.)> [tests deleted]> > Any help diagnosing the problem would be greatly appreciated. Thanks.> There isn't necessarily a problem at all. An SSL or TLS implementationis not guaranteed to support all ciphersuites so if the two sides do notshare a common ciphersuite a handshake error will occur.Current versions of Netscape, MSIE for example do not support DHEciphersuites at all. [BTW This is likely to change in future because I've donated DHE code tothe Mozilla project so it should support DHE ciphersuites at some point]Steve.-- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/Core developer of the OpenSSL project: http://www.openssl.org/Business Email: [EMAIL PROTECTED] PGP key: via homepage.__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
Handshake Failure with some ciphers
I wrote a little batch file to check that I can handshake with ALL the ciphers that are output from an "openssl ciphers" command. (BTW, I am running on a Windows 2000 box with the latest 0.9.6a build.) Unfortunately, some of the ciphers do not seem to work when passed in using an "openssl s_client -cipher XXX-XXX-XXX" command. (I am running a standard "openssl s_server" in another window.) Here is the batch file I am using: --allciphers.bat-- @echo offecho EDH-RSA-DES-CBC3-SHAopenssl s_client -cipher EDH-RSA-DES-CBC3-SHAecho EDH-DSS-DES-CBC3-SHAopenssl s_client -cipher EDH-DSS-DES-CBC3-SHAecho DES-CBC3-SHAopenssl s_client -cipher DES-CBC3-SHAecho DES-CBC3-MD5openssl s_client -cipher DES-CBC3-MD5echo DHE-DSS-RC4-SHAopenssl s_client -cipher DHE-DSS-RC4-SHAecho IDEA-CBC-SHAopenssl s_client -cipher IDEA-CBC-SHAecho RC4-SHAopenssl s_client -cipher RC4-SHAecho RC4-MD5openssl s_client -cipher RC4-MD5echo IDEA-CBC-MD5openssl s_client -cipher IDEA-CBC-MD5echo RC2-CBC-MD5openssl s_client -cipher RC2-CBC-MD5echo RC4-MD5openssl s_client -cipher RC4-MD5echo RC4-64-MD5openssl s_client -cipher RC4-64-MD5echo EXP1024-DHE-DSS-RC4-SHAopenssl s_client -cipher EXP1024-DHE-DSS-RC4-SHAecho EXP1024-RC4-SHAopenssl s_client -cipher EXP1024-RC4-SHAecho EXP1024-DHE-DSS-DES-CBC-SHAopenssl s_client -cipher EXP1024-DHE-DSS-DES-CBC-SHAecho EXP1024-DES-CBC-SHAopenssl s_client -cipher EXP1024-DES-CBC-SHAecho EXP1024-RC2-CBC-MD5openssl s_client -cipher EXP1024-RC2-CBC-MD5echo EXP1024-RC4-MD5openssl s_client -cipher EXP1024-RC4-MD5echo EDH-RSA-DES-CBC-SHAopenssl s_client -cipher EDH-RSA-DES-CBC-SHAecho EDH-DSS-DES-CBC-SHAopenssl s_client -cipher EDH-DSS-DES-CBC-SHAecho DES-CBC-SHAopenssl s_client -cipher DES-CBC-SHAecho DES-CBC-MD5openssl s_client -cipher DES-CBC-MD5echo EXP-EDH-RSA-DES-CBC-SHAopenssl s_client -cipher EXP-EDH-RSA-DES-CBC-SHAecho EXP-EDH-DSS-DES-CBC-SHAopenssl s_client -cipher EXP-EDH-DSS-DES-CBC-SHAecho EXP-DES-CBC-SHAopenssl s_client -cipher EXP-DES-CBC-SHAecho EXP-RC2-CBC-MD5openssl s_client -cipher EXP-RC2-CBC-MD5echo EXP-RC4-MD5openssl s_client -cipher EXP-RC4-MD5echo EXP-RC2-CBC-MD5openssl s_client -cipher EXP-RC2-CBC-MD5echo EXP-RC4-MD5openssl s_client -cipher EXP-RC4-MD5--end of allciphers.bat-- Most ciphers handshake correctly, but the following do not: EDH-DSS-DES-CBC3-SHADES-CBC3-MD5DHE-DSS-RC4-SHAIDEA-CBC-MD5RC2-CBC-MD5RC4-64-MD5EXP1024-DHE-DSS-RC4-SHAEXP1024-DHE-DSS-DES-CBC-SHAEDH-DSS-DES-CBC-SHADES-CBC-MD5EXP-EDH-DSS-DES-CBC-SHA The output on the client side shows: Loading 'screen' into random state - doneCONNECTED(01A4)1600:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:455: The output on the server side shows: Loading 'screen' into random state - doneUsing default temp DH parametersACCEPTERROR1832:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:.\ssl\s3_srvr.c:772:shutting down SSLCONNECTION CLOSEDACCEPT Any help diagnosing the problem would be greatly appreciated. Thanks. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com
Re: How to build openssl without certain license-encumberedalgorithms ?
The key is to update the ms\do_ms.bat file. I'm not sure that Configure does much on the Win32 platform. If you edit the do_ms.bat and pass no-rc4 no-rc5 no-idea into the perl scripts mk1mf.pl and mkdef.pl, you should see a difference. Good luck. Verdon Walker(801) 861-2633[EMAIL PROTECTED]Novell Inc., the leading provider of Net Services Softwarewww.novell.com>>> [EMAIL PROTECTED] 04/06/01 07:39AM >>>This should be an easy question for the experts.How can I build openssl.exe on the Windows NT platformwithout the license-encumbered algorithms ?The instructions within the INSTALL.W32 file are clear,but they don't seem to work.I am using the OpenSSL 0.9.3a source tree (for reasons which I won'tdescribe here).I am following the "Visual C++" instructions at the beginning of the"INSTALL.W32" file.To build openssl.exe I typically run the following command sequence:- perl Configure VC-WIN32- ms\do_ms- nmake -f ms\nt.mkopenssl.exe builds fine.To build openssl.exe to remove the "rc4, rc5 and idea" algorithms, forexample,I am instructed to modify the above command sequence as follows:- perl Configure VC-WIN32 no-rc4 no-rc5 no-idea- ms\do_ms- nmake -f ms\nt.mkThis doesn't work. No additional defines are used in the compilations andthe same size executable is generated as before.Manually adding -DNO_RC4 -DNO_RC5 and -DNO_IDEA to the CFLAGS andLIBFLAGS macros within nt.mak doesn't help. It only causes certaincompilationsto die within rc4.h, rc5.h, and idea.h respectively. Each of theseheader filesis written to fail to compile if its respective -DNO_* define exists.Please reply to "[EMAIL PROTECTED]".Thanks,MikeInternet Address: [EMAIL PROTECTED] Phone: (512)-436-9735Lotus Notes Address: MIKEAULT/TIVOLI SYSTEMS@TIVOLI SYSTEMS__OpenSSL Project http://www.openssl.orgDevelopment Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED]
