[PATYCH] typo in crypto/x509/x509_txt.c
This patch fixes a small typo in 0.9.[89]* Martin -- [EMAIL PROTECTED]| Fujitsu Siemens http://www.fujitsu-siemens.com/imprint.html | 81730 Munich, Germany Index: crypto/x509/x509_txt.c === RCS file: /home/cvs/OpenSSL/openssl/crypto/x509/x509_txt.c,v retrieving revision 1.21 diff -u -r1.21 x509_txt.c --- crypto/x509/x509_txt.c 27 Nov 2006 14:18:02 - 1.21 +++ crypto/x509/x509_txt.c 16 May 2007 10:03:38 - @@ -129,7 +129,7 @@ case X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED: return(proxy path length constraint exceeded); case X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED: - return(proxy cerificates not allowed, please set the appropriate flag); + return(proxy certificates not allowed, please set the appropriate flag); case X509_V_ERR_INVALID_PURPOSE: return (unsupported certificate purpose); case X509_V_ERR_CERT_UNTRUSTED:
[PATCH] openssl-0.9.7l make install fails in fips-1.0/ directory
Hello everyone,
I have a problem with openssl-0.9.7k and 0.9.7l;
I am not using FIPS (and the default also is to disable it).
On some platforms, I build the static libs only, and not the shared libs.
At least on these platforms I had problems when doing make install
in the to-level directory, because it tries to install nonexistent files:
--snip--
...
installing fips-1.0...
making install in fips/sha...
making install in fips/rand...
making install in fips/des...
making install in fips/aes...
making install in fips/dsa...
making install in fips/rsa...
making install in fips/dh...
making install in fips/hmac...
installing fipsld
cp: cannot stat `fipscanister.o': No such file or directory
cp: cannot stat `fipscanister.o.sha1': No such file or directory
*** Error code 1
make: Fatal error: Command failed for target `install'
Current working directory /home/martin/SRC/work/openssl-0.9.7l/fips-1.0
*** Error code 1
make: Fatal error: Command failed for target `install_sw'
(exit 1)
--snip--
The attached (ugly) patch fixes the problem by testing the install
target like it tests the build target (by checking for #define OPENSSL_FIPS).
Am I the only user who observes this problem?
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-48332 | 81730 Munich, Germany
diff --exclude=config.log --exclude='*.o' --exclude='*.a' --exclude='*~'
--exclude=cscope.out -burp openssl-0.9.7l.orig/fips-1.0/Makefile
openssl-0.9.7l/fips-1.0/Makefile
--- openssl-0.9.7l.orig/fips-1.0/Makefile 2006-03-28 14:10:37.0
+0200
+++ openssl-0.9.7l/fips-1.0/Makefile2006-09-29 12:03:37.699261000 +0200
@@ -159,28 +159,30 @@ fips_test: top tests
done;
install:
- @headerlist=$(EXHEADER); for i in $$headerlist ;\
+ @if egrep 'define OPENSSL_FIPS' $(TOP)/include/openssl/opensslconf.h
/dev/null; then \
+ headerlist=$(EXHEADER); for i in $$headerlist ;\
do \
(cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \
chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i );
\
- done;
- @for i in $(FDIRS) ;\
+ done \
+ for i in $(FDIRS) ;\
do \
(cd $$i echo making install in fips/$$i... \
$(MAKE) CC='$(CC)' CFLAG='${CFLAG}'
INSTALL_PREFIX='${INSTALL_PREFIX}' INSTALLTOP='${INSTALLTOP}'
PEX_LIBS='${PEX_LIBS}' EX_LIBS='${EX_LIBS}' install ); \
- done;
- @for i in $(EXE) ; \
+ done \
+ for i in $(EXE) ; \
do \
echo installing $$i; \
cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/bin/$$i.new; \
chmod 755 $(INSTALL_PREFIX)$(INSTALLTOP)/bin/$$i.new; \
mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/bin/$$i.new
$(INSTALL_PREFIX)$(INSTALLTOP)/bin/$$i; \
- done
- @cp -p -f fipscanister.o fipscanister.o.sha1 fips_premain.c \
- $(INSTALL_PREFIX)$(INSTALLTOP)/lib/; \
+ done \
+ cp -p -f fipscanister.o fipscanister.o.sha1 fips_premain.c \
+ $(INSTALL_PREFIX)$(INSTALLTOP)/lib/ \
strings fipscanister.o | grep HMAC-SHA1(fips_premain\\.c) \
- $(INSTALL_PREFIX)$(INSTALLTOP)/lib/fips_premain.c.sha1; \
- chmod 0444 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/fips*
+ $(INSTALL_PREFIX)$(INSTALLTOP)/lib/fips_premain.c.sha1 \
+ chmod 0444 $(INSTALL_PREFIX)$(INSTALLTOP)/lib/fips*; \
+ fi # if fips
lint:
@for i in $(FDIRS) ;\
critical,CA:FALSE but Any Purpose CA : Yes ?
When creating a certificate using an openssl CA, I specify the x509v3 extension basicConstraints = critical,CA:FALSE. Looking at the generated certificate using % openssl x509 -noout -text -purpose -in nonca.pem ... X509v3 Basic Constraints: critical CA:FALSE ... Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : No CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes == OCSP helper : Yes OCSP helper CA : No How can this be, CA usage is critically forbidden, yet the CA usage for Any Purpose is possible ??? Is this an openssl problem, or a misunderstanding on my side? Irritated, Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl verify returning both error and OK?
When testing a certificate for its allowed purposes, I found:
$ for purpose in sslclient sslserver nssslserver smimesign smimeencrypt crlsign
any ocsphelper
do
echo -n ${purpose}:
openssl-0.9.8 verify -verbose -CAfile ca_chain.txt -purpose $purpose my.pem
done
sslclient:my.pem: OK
sslserver:my.pem: OK
nssslserver:my.pem: OK
smimesign:my.pem: OK
smimeencrypt:my.pem: OK
crlsign:my.pem: /C=GB/O=Defer Test/OU=basic/CN=Martin Kraemer/[EMAIL PROTECTED]
error 26 at 0 depth lookup:unsupported certificate purpose
OK
any:my.pem: OK
ocsphelper:my.pem: OK
For the case of the crlsign purpose, shouldn't openssl die with
a non-OK error, instead of printing an error, but finally OK?
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: critical,CA:FALSE but Any Purpose CA : Yes ?
Since then CA checks have been made mandatory in the code even if Any Purpose is set. So if you actually tried to use that certificate as a CA it would be rejected. If that is so, then how can the following happen (with a recent openssl-dev): % openssl version -a OpenSSL 0.9.9-dev XX xxx built on: Wed Jun 29 12:31:27 CEST 2005 platform: BSD-x86-elf options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM OPENSSLDIR: /usr/local/ssl % openssl x509 -in [EMAIL PROTECTED] -noout -text -purpose Certificate: Data: Version: 3 (0x2) Serial Number: c0:ed:2a:bc:67:03:2a:69:c3:46:23:49:dd:a8:c3:a0 Signature Algorithm: sha1WithRSAEncryption Issuer: C=XY, O=BTG Development CA (3), OU=Basic CA, CN=David Deer/[EMAIL PROTECTED] Validity Not Before: Jul 5 11:05:50 2005 GMT Not After : Jul 7 11:05:50 2005 GMT Subject: C=XY, O=BTG Development CA (3), OU=Basic CA, CN=Martin Kraemer/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:...:29 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C4:40:46:89:F2:60:86:3A:23:80:CF:46:E2:B5:B4:48:BA:44:94:0F X509v3 Authority Key Identifier: keyid:23:B4:0C:4C:FA:26:E3:76:3B:02:7F:DC:CC:8D:24:D7:48:8C:95:E7 DirName:/C=XY/O=BTG Development CA (3)/CN=David Deer/[EMAIL PROTECTED] serial:C4:A5:4C:5D:BB:C3:89:C7:F8:8B:94:49:D8:C1:E2:0C X509v3 Subject Alternative Name: email:[EMAIL PROTECTED] X509v3 Issuer Alternative Name: email:[EMAIL PROTECTED] X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Key Agreement X509v3 CRL Distribution Points: URI:http://ca.example.com/ca/3/basic_C4A54C5DBBC389C7F88B9449D8C1E20C.crl Netscape CA Revocation Url: http://ca.example.com/ca/3/basic_C4A54C5DBBC389C7F88B9449D8C1E20C.crl Netscape Comment: created by BaDCA 1.3.6.1.4.1.18060.101.1: committer Signature Algorithm: sha1WithRSAEncryption 37:...:9a Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : No CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes OCSP helper : Yes OCSP helper CA : No % openssl ca -config openssl.cnf -cert [EMAIL PROTECTED] -keyfile [EMAIL PROTECTED] -verbose -in [EMAIL PROTECTED] Using configuration from openssl.cnf Enter pass phrase for [EMAIL PROTECTED]: ... 9 entries loaded from the database generating index message digest is md5 policy is policy_match next serial number is 0123456789ABCDEF0123456789ABCDF5 Certificate Request: Data: Version: 0 (0x0) Subject: CN=Martin Kraemer/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:...:29 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: md5WithRSAEncryption 53:...:60 Check that the request matches the signature Signature ok The subject name appears to be ok, checking data base for clashes Everything appears to be ok, creating and signing the certificate Successfully added extensions from config Certificate Details: Serial Number: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:f5 Validity Not Before: Jul 5 15:33:22 2005 GMT Not After : Jul 5 15:33:22 2006 GMT Subject: commonName= Martin Kraemer emailAddress = [EMAIL PROTECTED] X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: C4:40:46:89:F2:60:86:3A:23:80:CF:46:E2:B5:B4:48:BA:44:94:0F X509v3 Authority Key Identifier: keyid:C4:40:46:89:F2:60:86:3A:23:80:CF:46:E2:B5:B4:48:BA:44:94:0F DirName:/C=XY/O=BTG Development CA (3)/OU=Basic CA/CN=David Deer/[EMAIL PROTECTED
Re: critical,CA:FALSE but Any Purpose CA : Yes ?
On Tue, Jul 05, 2005 at 05:45:09PM +0200, Martin Kraemer wrote: If that is so, then how can the following happen (with a recent openssl-dev): Oops - it can because here, the critical flag is missing. Sorry. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #759] [PATCH] openssl-0.9.6l Makefile typo
There's a typo in the names for the shared object libraries under linux/390 which leads to libraries libcrypto.so.0,9.6 instead of libcrypto.so.0.9.6 being built. Martin --- openssl-0.9.6l/#Configure~ 2003-11-11 16:49:33.0 +0100 +++ openssl-0.9.6l/Configure2003-11-11 16:49:33.0 +0100 @@ -344,7 +344,7 @@ linux-mips, gcc:-DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::(unknown)::BN_LLONG:::, linux-ppc, gcc:-DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1 DES_UNROLL::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), linux-m68k, gcc:-DB_ENDIAN -DTERMIO -O2 -fomit-frame-pointer -Wall::-D_REENTRANT::BN_LLONG::, -linux-s390, gcc:-DB_ENDIAN -DTERMIO -DNO_ASM -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:-ldl:BN_LLONG::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR),\$(SHLIB_MINOR), +linux-s390, gcc:-DB_ENDIAN -DTERMIO -DNO_ASM -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:-ldl:BN_LLONG::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), linux-s390x, gcc:-DB_ENDIAN -DTERMIO -DNO_ASM -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:-ldl:SIXTY_FOUR_BIT_LONG::dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), linux-ia64, gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT:-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK RC4_CHAR:asm/ia64.o:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), NetBSD-sparc,gcc:-DTERMIOS -O3 -fomit-frame-pointer -mv8 -Wall -DB_ENDIAN::(unknown)::BN_LLONG MD2_CHAR RC4_INDEX DES_UNROLL::dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR), -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ 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] Howard Chu's EBCDIC-Port upgrade patch
On Mon, Mar 03, 2003 at 05:34:20PM +0100, Richard Levitte - VMS Whacker wrote: I'm surprised by how little seems to need changed. Is that really possible? I imagined the EBCDIC issue was a much bugger can of worms. The majority of the EBCDIC changes are already in the code, and run in production use (Apache+SSL) on our platforms. The code was written to mainly keep the internal data structures in ASCII, converting only to EBCDIC where the API offers access to, e.g., certificate data. The shortcomings are that some structures do not follow this design goal, but contain EBCDIC data (and some constants like TRUE/FALSE, used in the openssl application, have been literal EBCDIC strings instead of ASCII strings). Mr. Chu's patch fixes enough of them so that even make test runs to completion on an EBCDIC platform (which it does not if the patch is not applied). But, as I pointed out, there are a few more rare conversion cases which are not caught by make test, and are not completely fixed by the patch yet. My colleague says he has a solution for them too, but he wants to clean it up his patch first. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[PATCH] Howard Chu's EBCDIC-Port upgrade patch
Date: Fri, 28 Feb 2003 13:34:41 -0800
From: Howard Chu [EMAIL PROTECTED]
Subject: RE: EBCDIC
I ported OpenLDAP, OpenSSL, Berkeley DB 4.1, and part of Cyrus SASL to
OS/390. Aside from Cyrus, all of these packages were fully functional but
OpenLDAP and OpenSSL operate with ASCII internally. [...]
A lot of what I went thru is in the FAQ-o-Matic now
http://www.openldap.org/faq/data/cache/719.html
Hello Howard, hello OpenSSL developers,
Excellent resource, thanks. For the OpenSSL patches, you fixed some
longstanding bugs (I had been aware of the TRUE/FALSE constant strings
-which were misconverted in the EBCDIC version-, and I find your
solution to it elegant).
At
http://www.openldap.org/faq/index.cgi?file=745
you print the set of patches to OpenSSL, and I verified them to work
on our BS2000 version of OpenSSL as well - the do indeed fix the problems
in the openssl application. One minor nit: in apps/ca.c, you subtract
the literal EBCDIC-'@' from an EBCDIC-char to construct the control-char;
this will not work, you must use 0x40 instead of '@' (fixed in
attached patch).
I vote for including the patch into mainstream OpenSSL. I repeat the
('@'-fixed) Howard Chu EBCDIC patch in this mail because the version
from http://www.openldap.org/faq/index.cgi?file=745 does not
apply cleanly (HTML-escapes present).
OpenSSL developers: this patch is against 0.9.6i, and is verified to
work for the IBM OS/390 and Fujitsu-Siemens BS2000(OSD/POSIX)
EBCDIC versions.
Thank you,
Martin Kraemer
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
--- ./crypto/asn1/a_print.c.origMon Mar 3 11:41:37 2003
+++ ./crypto/asn1/a_print.c Mon Mar 3 11:42:32 2003
@@ -116,27 +116,18 @@
while ((*s) (len-- != 0))
{
c= *(s++);
-#ifndef CHARSET_EBCDIC
- if (!( ((c = 'a') (c = 'z')) ||
- ((c = 'A') (c = 'Z')) ||
- (c == ' ') ||
- ((c = '0') (c = '9')) ||
- (c == ' ') || (c == '\'') ||
- (c == '(') || (c == ')') ||
- (c == '+') || (c == ',') ||
- (c == '-') || (c == '.') ||
- (c == '/') || (c == ':') ||
- (c == '=') || (c == '?')))
- ia5=1;
if (c0x80)
+ {
t61=1;
-#else
- if (!isalnum(c) (c != ' ')
- strchr('()+,-./:=?, c) == NULL)
+ break;
+ }
+ if (!( ((c 0x40) (c 0x5b)) || /* AZ */
+ ((c 0x60) (c 0x7b)) || /* az */
+ ((c 0x2a) (c 0x3b)) || /* +,-./09: */
+ (c == 0x20) || (c == 0x27) || /* SPC, ' */
+ (c == 0x28) || (c == 0x29) || /* () */
+ (c == 0x3d) || (c == 0x3f)))/* =? */
ia5=1;
- if (os_toascii[c] 0x80)
- t61=1;
-#endif
}
if (t61) return(V_ASN1_T61STRING);
if (ia5) return(V_ASN1_IA5STRING);
--- ./apps/ca.c.origMon Mar 3 11:41:37 2003
+++ ./apps/ca.c Mon Mar 3 11:42:11 2003
@@ -1603,13 +1603,22 @@
p=(char *)str-data;
for (j=str-length; j0; j--)
{
+#ifdef CHARSET_EBCDIC
+ if ((*p = 0x20) (*p = 0x7e))
+ BIO_printf(bio_err,%c, os_toebcdic[*p]);
+#else
if ((*p = ' ') (*p = '~'))
BIO_printf(bio_err,%c,*p);
+#endif
else if (*p 0x80)
BIO_printf(bio_err,\\0x%02X,*p);
else if ((unsigned char)*p == 0xf7)
BIO_printf(bio_err,^?);
+#ifdef CHARSET_EBCDIC
+ elseBIO_printf(bio_err,^%c,os_toebcdic[*p+0x40]);
+#else
elseBIO_printf(bio_err,^%c,*p+'@');
+#endif
p++;
}
BIO_printf(bio_err,'\n);
--- ./crypto/x509v3/v3_alt.c.orig Thu Mar 1 14:33:53 2001
+++ ./crypto/x509v3/v3_alt.cMon Mar 3 11:44:22 2003
@@ -99,6 +99,15 @@
return ret;
}
+#ifdef CHARSET_EBCDIC
+static const char _unsup[] = {0x3c,0x75,0x6e,0x73,0x75,0x70,0x70,0x6f,
+ 0x72,0x74,0x65,0x64,0x3e,0 };
+static const char _inval[] = {0x3c,0x69,0x6e,0x76,0x61,0x6c,0x69,0x64,0x3e,0};
+#else
+static const char _unsup[] = lt;unsupportedgt;;
+static const char _inval[] = lt;invalidgt;;
+#endif
+
STACK_OF(CONF_VALUE) *i2v_GENERAL_NAME(X509V3_EXT_METHOD *method,
GENERAL_NAME *gen, STACK_OF(CONF_VALUE) *ret)
{
@@ -107,15 +116,15 @@
switch (gen-type)
{
case GEN_OTHERNAME
Re: [PATCH] Howard Chu's EBCDIC-Port upgrade patch
I vote for including the patch into mainstream OpenSSL. I repeat the
('@'-fixed) Howard Chu EBCDIC patch in this mail because the version
from http://www.openldap.org/faq/index.cgi?file=745 does not
apply cleanly (HTML-escapes present).
Oops - I fell into the same trap (HTML-frontends for mailing lists
have to convert plain text to HTML, or they will not be displayed
correctly.).
Look what I posted:
Content-Description: EBCDIC patch to crypto/x509v3/v3_alt.c
--- ./crypto/x509v3/v3_alt.c.orig Thu Mar 1 14:33:53 2001
+++ ./crypto/x509v3/v3_alt.c Mon Mar 3 11:44:22 2003
@@ -99,6 +99,15 @@
return ret;
}
+#ifdef CHARSET_EBCDIC
+static const char _unsup[] = {0x3c,0x75,0x6e,0x73,0x75,0x70,0x70,0x6f,
+ 0x72,0x74,0x65,0x64,0x3e,0 };
+static const char _inval[] = {0x3c,0x69,0x6e,0x76,0x61,0x6c,0x69,0x64,0x3e,0};
+#else
+static const char _unsup[] = lt;unsupportedgt;;
+static const char _inval[] = lt;invalidgt;;
----
Sorry for the hassle. Fixed version attached. But a colleague of mine
pointed out that in crypto/x509v3/v3_alt.c, two more conversions
must be applied to i2v_GENERAL_NAME() for the types GEN_DNS and GEN_URI
in addition to the conversion for GEN_DIRNAME. He is working on an
alternative patch to include these two.
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
--- ./crypto/x509v3/v3_alt.c.orig Thu Mar 1 14:33:53 2001
+++ ./crypto/x509v3/v3_alt.cMon Mar 3 11:44:22 2003
@@ -99,6 +99,15 @@
return ret;
}
+#ifdef CHARSET_EBCDIC
+static const char _unsup[] = {0x3c,0x75,0x6e,0x73,0x75,0x70,0x70,0x6f,
+ 0x72,0x74,0x65,0x64,0x3e,0 };
+static const char _inval[] = {0x3c,0x69,0x6e,0x76,0x61,0x6c,0x69,0x64,0x3e,0};
+#else
+static const char _unsup[] = unsupported;
+static const char _inval[] = invalid;
+#endif
+
STACK_OF(CONF_VALUE) *i2v_GENERAL_NAME(X509V3_EXT_METHOD *method,
GENERAL_NAME *gen, STACK_OF(CONF_VALUE) *ret)
{
@@ -107,15 +116,15 @@
switch (gen-type)
{
case GEN_OTHERNAME:
- X509V3_add_value(othername,unsupported, ret);
+ X509V3_add_value(othername,_unsup, ret);
break;
case GEN_X400:
- X509V3_add_value(X400Name,unsupported, ret);
+ X509V3_add_value(X400Name,_unsup, ret);
break;
case GEN_EDIPARTY:
- X509V3_add_value(EdiPartyName,unsupported, ret);
+ X509V3_add_value(EdiPartyName,_unsup, ret);
break;
case GEN_EMAIL:
@@ -132,6 +141,9 @@
case GEN_DIRNAME:
X509_NAME_oneline(gen-d.dirn, oline, 256);
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(oline, oline, strlen(oline));
+#endif
X509V3_add_value(DirName,oline, ret);
break;
@@ -139,15 +151,21 @@
p = gen-d.ip-data;
/* BUG: doesn't support IPV6 */
if(gen-d.ip-length != 4) {
- X509V3_add_value(IP Address,invalid, ret);
+ X509V3_add_value(IP Address,_inval, ret);
break;
}
sprintf(oline, %d.%d.%d.%d, p[0], p[1], p[2], p[3]);
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(oline, oline, strlen(oline));
+#endif
X509V3_add_value(IP Address,oline, ret);
break;
case GEN_RID:
i2t_ASN1_OBJECT(oline, 256, gen-d.rid);
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(oline, oline, strlen(oline));
+#endif
X509V3_add_value(Registered ID,oline, ret);
break;
}
@@ -383,6 +401,9 @@
}
if(is_string) {
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(value, value, strlen(value));
+#endif
if(!(gen-d.ia5 = M_ASN1_IA5STRING_new()) ||
!ASN1_STRING_set(gen-d.ia5, (unsigned char*)value,
strlen(value))) {
--- ./crypto/asn1/a_print.c.origMon Mar 3 11:41:37 2003
+++ ./crypto/asn1/a_print.c Mon Mar 3 11:42:32 2003
@@ -116,27 +116,18 @@
while ((*s) (len-- != 0))
{
c= *(s++);
-#ifndef CHARSET_EBCDIC
- if (!( ((c = 'a') (c = 'z')) ||
- ((c = 'A') (c = 'Z')) ||
- (c == ' ') ||
- ((c = '0') (c = '9')) ||
- (c == ' ') || (c == '\'') ||
- (c == '(') || (c == ')') ||
- (c == '+') || (c == ',') ||
- (c == '-') || (c == '.') ||
- (c == '/') || (c == ':') ||
- (c == '=') || (c == '?')))
- ia5=1;
if (c0x80)
+ {
t61=1;
[PATCH] Proposed proxy client functionality in s_client
I had to test a couple of proxy servers lately which had problems passing
CONNECT connections. I was missing a tool like s_client but using a
proxy, so I added a quick hack to s_client. This patch adds a switch
$ openssl s_client -proxy myproxy:8080 -connect remoteserver:443
-^^^
which tunnels the secure connection over an HTTP proxy tunnel.
I call it a hack because
a) I think there must be better ways to receive the response
HTTP/1.x 200 OK from the proxy but read()ing it directly
b) the echo of the proxy response should be filtered to display
only for the appropriate -verbosity level.
c) no attempt is made to catch connection errors or responses
other than 200 OK from the proxy (think of -proxyauth user:pass)
Anyway, I thought someone might find this useful, so feel free to improve!
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
? apps/cscope.out
Index: apps/s_client.c
===
RCS file: /home/cvs/OpenSSL/openssl/apps/s_client.c,v
retrieving revision 1.56
diff -u -r1.56 s_client.c
--- apps/s_client.c 16 Jul 2002 06:52:03 - 1.56
+++ apps/s_client.c 3 Sep 2002 13:26:49 -
@@ -182,6 +182,7 @@
BIO_printf(bio_err, -host host - use -connect instead\n);
BIO_printf(bio_err, -port port - use -connect instead\n);
BIO_printf(bio_err, -connect host:port - who to connect to (default is
%s:%s)\n,SSL_HOST_NAME,PORT_STR);
+ BIO_printf(bio_err, -proxy pxhost:pxport - use this proxy to access the
+host:port server\n);
BIO_printf(bio_err, -verify arg - turn on peer certificate verification\n);
BIO_printf(bio_err, -cert arg - certificate file to use, PEM format
assumed\n);
@@ -232,8 +233,10 @@
int sbuf_len,sbuf_off;
fd_set readfds,writefds;
short port=PORT;
+ short pxport=0;
int full_log=1;
char *host=SSL_HOST_NAME;
+ char *pxhost=NULL;
char *cert_file=NULL,*key_file=NULL;
char *CApath=NULL,*CAfile=NULL,*cipher=NULL;
int reconnect=0,badop=0,verify=SSL_VERIFY_NONE,bugs=0;
@@ -309,6 +312,12 @@
if (!extract_host_port(*(++argv),host,NULL,port))
goto bad;
}
+ else if (strcmp(*argv,-proxy) == 0)
+ {
+ if (--argc 1) goto bad;
+ if (!extract_host_port(*(++argv),pxhost,NULL,pxport))
+ goto bad;
+ }
else if (strcmp(*argv,-verify) == 0)
{
verify=SSL_VERIFY_PEER;
@@ -510,7 +519,37 @@
re_start:
- if (init_client(s,host,port) == 0)
+ if (pxhost pxport)
+ {
+ char *hdr_str = NULL;
+ char buf[1024];
+ int rx;
+ if (init_client(s,pxhost,pxport) == 0)
+ {
+ BIO_printf(bio_err,proxy:errno=%d\n,get_last_socket_error());
+ SHUTDOWN(s);
+ goto end;
+ }
+ if ((hdr_str =
+OPENSSL_malloc(2*strlen(host)+strlen(pxhost)+sizeof(CONNECT :65535 HTTP/1.0\r\nVia:
+\r\nHost: :65535\r\n\r\n))) == NULL)
+ {
+ BIO_printf(bio_err,proxy:out of memory\n);
+ goto end;
+ }
+ sprintf(hdr_str,CONNECT %s:%u HTTP/1.0\r\n
+ Via: %s\r\n
+ Host: %s:%u\r\n\r\n,
+ host,port, pxhost, host,port);
+ write(s, hdr_str, strlen(hdr_str));
+ OPENSSL_free(hdr_str);
+ if ((rx = read(s,buf,sizeof buf - 1)) 1)
+ {
+ BIO_printf(bio_err,proxy:no response from proxy\n);
+ goto end;
+ }
+ buf[rx] = '\0';
+ BIO_printf(bio_err, %s, buf);
+ }
+ else if (init_client(s,host,port) == 0)
{
BIO_printf(bio_err,connect:errno=%d\n,get_last_socket_error());
SHUTDOWN(s);
[openssl.org #266] [PATCH] Proposed proxy client functionality in s_client
I had to test a couple of proxy servers lately which had problems passing CONNECT connections. I was missing a tool like s_client but using a proxy, so I added a quick hack to s_client. This patch adds a switch $ openssl s_client -proxy myproxy:8080 -connect remoteserver:443 -^^^ which tunnels the secure connection over an HTTP proxy tunnel. I call it a hack because a) I think there must be better ways to receive the response HTTP/1.x 200 OK from the proxy but read()ing it directly b) the echo of the proxy response should be filtered to display only for the appropriate -verbosity level. c) no attempt is made to catch connection errors or responses other than 200 OK from the proxy (think of -proxyauth user:pass) Anyway, I thought someone might find this useful, so feel free to improve! Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
NID_uniqueIdentifier got (partially) lost?
When trying to compile apache+mod_ssl against a recent snapshot of
openssl-0.9.8-dev (?), I get compile errors because the #define for
NID_uniqueIdentifier
is no longer present. It used to be both in objects.h and in obj_mac.h
(and is referenced in ssl_engine_vars.c):
cscope:
0 ssl_engine_vars.c global 410 { UID, NID_uniqueIdentifier },
1 objects.h global 557 #define NID_uniqueIdentifier 102
2 obj_mac.h global 1550 #define NID_uniqueIdentifier 102
Now the funny thing is that the variable is still present in an up-to-date
copy of objects.h, but it has vanished from obj_mac.h (but USE_OBJ_MAC
is set so it is only #included freom the latter).
It appears that a renaming has happened, as the string UID is still
present in both include files, albeit with a different definition:
---obj_mac.h:---
#define SN_userId UID
#define LN_userId userId
#define NID_userId 458
#define OBJ_userId OBJ_pilotAttributeType,1L
---objects.h:---
#define SN_uniqueIdentifier UID
#define LN_uniqueIdentifier uniqueIdentifier
#define NID_uniqueIdentifier102
#define OBJ_uniqueIdentifierOBJ_X509,45L
And it is the UID which mod_ssl tries to decode:
static const struct {
char *name;
int nid;
} ssl_var_lookup_ssl_cert_dn_rec[] = {
...
{ UID, NID_uniqueIdentifier },
...
{ NULL,0 }
};
So, which file is correct, or: why was obj_mac.h fixed, but objects.h
wasn't?
Puzzled,
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
OpenSSL date
I just built what I extracted from CVS, and openssl version said: OpenSSL 0.9.8-dev 24 Sep 2000 Isn't it time to update the old 24 Sep 2000 now that a major release is forthcoming? Just my EUR .02 Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Current CVS does not compile with no-idea
When incoking ./config no-idea and compiling, I get this: gcc -DMONOLITH -I.. -I../include -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_THREAD -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c version.c In file included from version.c:121: ../include/openssl/idea.h:63: #error IDEA is disabled. *** Error code 1 Stop in .../openssl-0.9.7-dev/apps. *** Error code 1 Stop in .../openssl-0.9.7-dev. This patch fixes that: --snip-- Index: apps/version.c === RCS file: /home/cvs/OpenSSL/openssl/apps/version.c,v retrieving revision 1.12 diff -u -r1.12 version.c --- apps/version.c 2001/10/24 21:20:18 1.12 +++ apps/version.c 2001/11/14 08:31:24 @@ -118,7 +118,9 @@ #include openssl/md2.h #include openssl/rc4.h #include openssl/des_old.h +#ifndef OPENSSL_NO_IDEA #include openssl/idea.h +#endif #include openssl/blowfish.h #undef PROG --snip-- Cheers, Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Bus Error in RSA_free() on FreeBSD-4.4
I recompiled Apache-1.3.22 with mod_ssl-2.8.5 and OpenSSL-0.9.7-dev
today. Alas, I always get a core dump if I enable mod_ssl (as a DSO).
I traced it to the following point:
$ gdb sbin/httpd
(gdb) b ap_init_modules
(gdb) r -X -DSSL
...
(gdb) b ssl_engine_init.c:397
Breakpoint 2 at 0x2852042e: file ssl_engine_init.c, line 397.
(gdb) c
Continuing.
Breakpoint 2, ssl_init_TmpKeysHandle (action=0, s=0x8153034, p=0x815300c)
at ssl_engine_init.c:397
397 RSA_free(rsa);
(gdb) p *rsa
$19 = {pad = 0, version = 0, meth = 0x8142480, engine = 0x81f6de0, n = 0x81f6d40,
e = 0x81f6e00, d = 0x81f6da0, p = 0x81f6d60, q = 0x81f6e40, dmp1 = 0x81f6e60,
dmq1 = 0x81f6ea0, iqmp = 0x0, ex_data = {sk = 0x0, dummy = 0}, references = 1,
flags = 6, _method_mod_n = 0x0, _method_mod_p = 0x0, _method_mod_q = 0x0,
bignum_data = 0x0, blinding = 0x0}
(gdb) s
0x2851b108 in _init () from /opt/apache/libexec/libssl.so
(gdb)
Single stepping until exit from function _init,
which has no line number information.
Program received signal SIGBUS, Bus error.
0x823d082 in ?? ()
(gdb)
Is this an OpenSSL problem? Or a mod_ssl problem?
Puzzled, and recompiling openssl-0.9.7-dev with -g to supply more
traces,
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[PATCH] Fix error (and possible dump) in speed.c
There's a typo in speed.c which creates a core dump if (for any reason)
no rsa verify operation was performed.
--snip--
--- apps/speed.c.orig Fri Mar 16 11:18:34 2001
+++ apps/speed.cFri Mar 16 11:09:27 2001
@@ -1207,7 +1207,7 @@
{
BIO_printf(bio_err,"RSA verify failure. No RSA verify will be
done.\n");
ERR_print_errors(bio_err);
- dsa_doit[j] = 0;
+ rsa_doit[j] = 0;
}
else
{
--snip--
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[PATCH] EBCDIC patches against current CVS tree
Here's the set of EBCDIC patches again which make openssl-0.9.5a and
openssl-0.9.6-dev work better: X509v3 attributes were handled incorrectly
and caused errors in a_mbstr.c when using the "openssl x509" and "req"
commands.
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany
? ebcdic.diff
Index: apps/req.c
===
RCS file: /home/cvs/OpenSSL/openssl/apps/req.c,v
retrieving revision 1.62
diff -u -r1.62 req.c
--- apps/req.c 2000/07/12 23:55:28 1.62
+++ apps/req.c 2000/08/21 13:02:15
@@ -1099,7 +1099,11 @@
* multiple instances
*/
for(p = v-name; *p ; p++)
+#ifndef CHARSET_EBCDIC
if ((*p == ':') || (*p == ',') || (*p == '.')) {
+#else
+ if ((*p == os_toascii[':']) || (*p == os_toascii[',']) || (*p
+== os_toascii['.'])) {
+#endif
p++;
if(*p) type = p;
break;
@@ -1215,6 +1219,9 @@
return(0);
}
buf[--i]='\0';
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(buf, buf, i);
+#endif
if(!req_check_len(i, min, max)) goto start;
if(!X509_REQ_add1_attr_by_NID(req, nid, MBSTRING_ASC,
Index: crypto/asn1/a_mbstr.c
===
RCS file: /home/cvs/OpenSSL/openssl/crypto/asn1/a_mbstr.c,v
retrieving revision 1.10
diff -u -r1.10 a_mbstr.c
--- crypto/asn1/a_mbstr.c 2000/06/05 13:50:57 1.10
+++ crypto/asn1/a_mbstr.c 2000/08/21 13:02:17
@@ -382,9 +382,16 @@
/* Note: we can't use 'isalnum' because certain accented
* characters may count as alphanumeric in some environments.
*/
+#ifndef CHARSET_EBCDIC
if((ch = 'a') (ch = 'z')) return 1;
if((ch = 'A') (ch = 'Z')) return 1;
if((ch = '0') (ch = '9')) return 1;
if ((ch == ' ') || strchr("'()+,-./:=?", ch)) return 1;
+#else /*CHARSET_EBCDIC*/
+ if((ch = os_toascii['a']) (ch = os_toascii['z'])) return 1;
+ if((ch = os_toascii['A']) (ch = os_toascii['Z'])) return 1;
+ if((ch = os_toascii['0']) (ch = os_toascii['9'])) return 1;
+ if ((ch == os_toascii[' ']) || strchr("'()+,-./:=?", os_toebcdic[ch])) return
+1;
+#endif /*CHARSET_EBCDIC*/
return 0;
}
Index: crypto/x509v3/v3_utl.c
===
RCS file: /home/cvs/OpenSSL/openssl/crypto/x509v3/v3_utl.c,v
retrieving revision 1.18
diff -u -r1.18 v3_utl.c
--- crypto/x509v3/v3_utl.c 2000/06/11 12:18:11 1.18
+++ crypto/x509v3/v3_utl.c 2000/08/21 13:02:24
@@ -351,6 +351,10 @@
*q++ = ':';
}
q[-1] = 0;
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(tmp, tmp, q - tmp - 1);
+#endif
+
return tmp;
}
@@ -369,8 +373,15 @@
if(!(hexbuf = OPENSSL_malloc(strlen(str) 1))) goto err;
for(p = (unsigned char *)str, q = hexbuf; *p;) {
ch = *p++;
+#ifdef CHARSET_EBCDIC
+ ch = os_toebcdic[ch];
+#endif
+
if(ch == ':') continue;
cl = *p++;
+#ifdef CHARSET_EBCDIC
+ cl = os_toebcdic[cl];
+#endif
if(!cl) {
X509V3err(X509V3_F_STRING_TO_HEX,X509V3_R_ODD_NUMBER_OF_DIGITS);
OPENSSL_free(hexbuf);
No Subject
Hi, When accessing the CVS tree of openssl, I noticed that many files have the "binary" attribute (cvs rcs -kb) which means they are not treated like text files. On unix, that does not change the handling at all, on Windoze, it makes the \r at the line ends disappear (i.e., makes text files very hard to read) and on an EBCDIC-based CVS client, it makes the text file appear as garbage (ascii file in ebcdic environment). Check it like this: cd $CVSROOT find openssl/ -name \*,v | xargs grep -a "expand.*@b@" I would propose to fix _at_least_ the following: find openssl/ -name '*,v' \ \( -name '*.[ch],v' -o -name '*.c*,v' \ -o -name Makefile.ssl \) | xargs grep -a "expand.*@b@" openssl/crypto/Attic/date.h,v:expand@b@; openssl/crypto/bf/bf_locl.h,v:expand@b@; openssl/crypto/bn/asm/Attic/..add.c,v:expand@b@; openssl/crypto/bn/bn.h,v:expand @b@; openssl/crypto/des/des.h,v:expand @b@; openssl/crypto/des/des_locl.h,v:expand @b@; openssl/crypto/idea/idea.h,v:expand @b@; openssl/crypto/md2/md2.h,v:expand @b@; openssl/crypto/rc2/rc2.h,v:expand @b@; openssl/crypto/rc4/rc4.h,v:expand @b@; openssl/crypto/rc4/rc4_locl.h,v:expand @b@; and possibly the *.pem and *.doc files. Fixing is easy, like: find openssl/ -name '*,v' \ \( -name '*.[ch],v' -o -name '*.c*,v' \ -o -name Makefile.ssl \) | cut -d, -f1 | xargs rcs -kkv Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
EBCDIC fixes for openssl-0.9.5a
Hi again,
Here are some fixes for EBCDIC systems. The "string correctness" test
routines in asn1/a_mbstr.c were not prepared for EBCDIC yet.
Also, I *think* I also fixed a bug in req.c which didn't convert
a line read from the user (at least, Ralf's mkcert.sh and an Apache+mod_ssl
server work fine with this patch).
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany
--- apps/req.c.orig Tue Mar 14 00:54:07 2000
+++ apps/req.c Thu Jul 20 01:14:04 2000
@@ -1081,11 +1081,15 @@
type=v-name;
/* Skip past any leading X. X: X, etc to allow for
* multiple instances
*/
for(p = v-name; *p ; p++)
+#ifndef CHARSET_EBCDIC
if ((*p == ':') || (*p == ',') || (*p == '.')) {
+#else
+ if ((*p == os_toascii[':']) || (*p == os_toascii[',']) || (*p
+== os_toascii['.'])) {
+#endif
p++;
if(*p) type = p;
break;
}
if (!X509_NAME_add_entry_by_txt(subj,type, MBSTRING_ASC,
@@ -1197,10 +1201,13 @@
{
BIO_printf(bio_err,"weird input :-(\n");
return(0);
}
buf[--i]='\0';
+#ifdef CHARSET_EBCDIC
+ ebcdic2ascii(buf, buf, i);
+#endif
if(!req_check_len(i, min, max)) goto start;
if(!X509_REQ_add1_attr_by_NID(req, nid, MBSTRING_ASC,
(unsigned char *)buf, -1)) {
BIO_printf(bio_err, "Error adding attribute\n");
--- crypto/asn1/a_mbstr.c.orig Thu Jul 20 01:16:14 2000
+++ crypto/asn1/a_mbstr.c Thu Jul 20 01:34:05 2000
@@ -380,11 +380,18 @@
if(value 0x7f) return 0;
ch = (int) value;
/* Note: we can't use 'isalnum' because certain accented
* characters may count as alphanumeric in some environments.
*/
+#ifndef CHARSET_EBCDIC
if((ch = 'a') (ch = 'z')) return 1;
if((ch = 'A') (ch = 'Z')) return 1;
if((ch = '0') (ch = '9')) return 1;
if ((ch == ' ') || strchr("'()+,-./:=?", ch)) return 1;
+#else /*CHARSET_EBCDIC*/
+ if((ch = os_toascii['a']) (ch = os_toascii['z'])) return 1;
+ if((ch = os_toascii['A']) (ch = os_toascii['Z'])) return 1;
+ if((ch = os_toascii['0']) (ch = os_toascii['9'])) return 1;
+ if ((ch == os_toascii[' ']) || strchr("'()+,-./:=?", os_toebcdic[ch])) return
+1;
+#endif /*CHARSET_EBCDIC*/
return 0;
}
[EBCDIC] Repost of ebcdic.c, and code fix for SSLv3
Here's the code for the missing file ebcdic.c, with the Apache copyright
removed (I'm the original author, and have consulted the IBM porter who
added the IBM-1047 EBCDIC table).
Also, a conversion error in SSLv3 ASN1 decoding is fixed.
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730 Munich, Germany
diff -Nbur openssl-0.9.4.orig openssl-0.9.4
--- /dev/null Wed Jan 26 15:20:02 2000
+++ openssl-0.9.4/crypto/ebcdic.c Wed Jan 26 15:08:32 2000
@@ -0,0 +1,211 @@
+#ifdef CHARSET_EBCDIC
+#include "ebcdic.h"
+/* Initial Port for Apache-1.3 by [EMAIL PROTECTED]
+ * Adapted for OpenSSL-0.9.4 by [EMAIL PROTECTED]
+ */
+
+#ifdef _OSD_POSIX
+/*
+"BS2000 OSD" is a POSIX subsystem on a main frame.
+It is made by Siemens AG, Germany, for their BS2000 mainframe machines.
+Within the POSIX subsystem, the same character set was chosen as in
+"native BS2000", namely EBCDIC. (EDF04)
+
+The name "ASCII" in these routines is misleading: actually, conversion
+is not between EBCDIC and ASCII, but EBCDIC(EDF04) and ISO-8859.1;
+that means that (western european) national characters are preserved.
+
+This table is identical to the one used by rsh/rcp/ftp and other POSIX tools.
+*/
+
+/* Here's the bijective ebcdic-to-ascii table: */
+const unsigned char os_toascii[256] = {
+/*00*/ 0x00, 0x01, 0x02, 0x03, 0x85, 0x09, 0x86, 0x7f,
+ 0x87, 0x8d, 0x8e, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, /**/
+/*10*/ 0x10, 0x11, 0x12, 0x13, 0x8f, 0x0a, 0x08, 0x97,
+ 0x18, 0x19, 0x9c, 0x9d, 0x1c, 0x1d, 0x1e, 0x1f, /**/
+/*20*/ 0x80, 0x81, 0x82, 0x83, 0x84, 0x92, 0x17, 0x1b,
+ 0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x05, 0x06, 0x07, /**/
+/*30*/ 0x90, 0x91, 0x16, 0x93, 0x94, 0x95, 0x96, 0x04,
+ 0x98, 0x99, 0x9a, 0x9b, 0x14, 0x15, 0x9e, 0x1a, /**/
+/*40*/ 0x20, 0xa0, 0xe2, 0xe4, 0xe0, 0xe1, 0xe3, 0xe5,
+ 0xe7, 0xf1, 0x60, 0x2e, 0x3c, 0x28, 0x2b, 0x7c, /* .`.(+|*/
+/*50*/ 0x26, 0xe9, 0xea, 0xeb, 0xe8, 0xed, 0xee, 0xef,
+ 0xec, 0xdf, 0x21, 0x24, 0x2a, 0x29, 0x3b, 0x9f, /*.!$*);.*/
+/*60*/ 0x2d, 0x2f, 0xc2, 0xc4, 0xc0, 0xc1, 0xc3, 0xc5,
+ 0xc7, 0xd1, 0x5e, 0x2c, 0x25, 0x5f, 0x3e, 0x3f, /*-/^,%_?*/
+/*70*/ 0xf8, 0xc9, 0xca, 0xcb, 0xc8, 0xcd, 0xce, 0xcf,
+ 0xcc, 0xa8, 0x3a, 0x23, 0x40, 0x27, 0x3d, 0x22, /*..:#@'="*/
+/*80*/ 0xd8, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+ 0x68, 0x69, 0xab, 0xbb, 0xf0, 0xfd, 0xfe, 0xb1, /*.abcdefghi..*/
+/*90*/ 0xb0, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70,
+ 0x71, 0x72, 0xaa, 0xba, 0xe6, 0xb8, 0xc6, 0xa4, /*.jklmnopqr..*/
+/*a0*/ 0xb5, 0xaf, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78,
+ 0x79, 0x7a, 0xa1, 0xbf, 0xd0, 0xdd, 0xde, 0xae, /*..stuvwxyz..*/
+/*b0*/ 0xa2, 0xa3, 0xa5, 0xb7, 0xa9, 0xa7, 0xb6, 0xbc,
+ 0xbd, 0xbe, 0xac, 0x5b, 0x5c, 0x5d, 0xb4, 0xd7, /*...[\]..*/
+/*c0*/ 0xf9, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
+ 0x48, 0x49, 0xad, 0xf4, 0xf6, 0xf2, 0xf3, 0xf5, /*.ABCDEFGHI..*/
+/*d0*/ 0xa6, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50,
+ 0x51, 0x52, 0xb9, 0xfb, 0xfc, 0xdb, 0xfa, 0xff, /*.JKLMNOPQR..*/
+/*e0*/ 0xd9, 0xf7, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58,
+ 0x59, 0x5a, 0xb2, 0xd4, 0xd6, 0xd2, 0xd3, 0xd5, /*..STUVWXYZ..*/
+/*f0*/ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+ 0x38, 0x39, 0xb3, 0x7b, 0xdc, 0x7d, 0xda, 0x7e /*0123456789.{.}.~*/
+};
+
+
+/* The ascii-to-ebcdic table: */
+const unsigned char os_toebcdic[256] = {
+/*00*/ 0x00, 0x01, 0x02, 0x03, 0x37, 0x2d, 0x2e, 0x2f,
+ 0x16, 0x05, 0x15, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, /**/
+/*10*/ 0x10, 0x11, 0x12, 0x13, 0x3c, 0x3d, 0x32, 0x26,
+ 0x18, 0x19, 0x3f, 0x27, 0x1c, 0x1d, 0x1e, 0x1f, /**/
+/*20*/ 0x40, 0x5a, 0x7f, 0x7b, 0x5b, 0x6c, 0x50, 0x7d,
+ 0x4d, 0x5d, 0x5c, 0x4e, 0x6b, 0x60, 0x4b, 0x61, /* !"#$%'()*+,-./ */
+/*30*/ 0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
+ 0xf8, 0xf9, 0x7a, 0x5e, 0x4c, 0x7e, 0x6e, 0x6f, /*0123456789:;=?*/
+/*40*/ 0x7c, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7,
+ 0xc8, 0xc9, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, /*@ABCDEFGHIJKLMNO*/
+/*50*/ 0xd7, 0xd8, 0xd9, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6,
+ 0xe7, 0xe8, 0xe9, 0xbb, 0xbc, 0xbd, 0x6a, 0x6d, /*PQRSTUVWXYZ[\]^_*/
+/*60*/ 0x4a, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+ 0x88, 0x89, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, /*`abcdefghijklmno*/
+/*70*/ 0x97, 0x98, 0x99, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6,
+ 0xa7, 0xa8, 0xa9, 0xfb, 0x4f, 0xfd, 0xff, 0x07, /*pqrstuvwxyz{|}~.*/
+/*80*/ 0x20, 0x21, 0x22, 0x23, 0x24, 0x04, 0x06, 0x08,
+ 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x09, 0x0a, 0x14, /**/
+/*90*/ 0x30, 0x31, 0x25, 0x33, 0x34, 0x35, 0x36, 0x17,
+ 0x38, 0x39, 0x3a, 0x3b, 0x1a, 0x1b, 0x3e, 0x5f, /**/
+/*a0*/ 0x41, 0xaa, 0xb0, 0xb1,
EBCDIC copyrights (again)
Hi, After a long pause of silence let me bring up the EBCDIC topic again. In May, I posted the patches for EBCDIC machines which were supposed to work on Siemens' BS2000 machines (and were prepared to run on other EBCDIC based platforms, mainly IBM's). In the file ebcdic.c, however, I had left the Apache Group's copyright message because I was unsure of the contribution status -- I was the original author, but I had contributed the source to The Apache Group. After discussing this with Ralf(rse) and some of the other Apache Members, I am confident that I am entitled to change that copyright to OpenSSL's (as far as my own code is concerned) but there is another problem: I had copied a second EBCDIC - ASCII translation table from the IBM TPF tree of The Apache Server. It is slightly different from BS2000's. If I change the copyright, then I would have to take out that part of the code. (That's allright with me, because currently I don't need the IBM tables myself, but it would make using the EBCDIC port much more difficult for IBM users). What's your understanding of this situation? Should I go ahead and re-post the updated ebcdic.c with the IBM table removed (and a note added where to get it)? Uncertain, Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSLeay EBCDIC
I tried to Cc this to [EMAIL PROTECTED], but it bounced. I'll re-try with [EMAIL PROTECTED]. You don't happen to use sendmail, do you? Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany On Fri, May 14, 1999 at 05:44:02PM +0200, Louis Kotze wrote: Hi Martin, I am about to embark of porting OpenSSL to the OS/390 platform, as EBCDIC is mainly used for the IBM world, I am curious as to porting you have done and if it is for the OS/390 platform can I get any assistance ? I have not ported to an IBM platform, but to Siemens' own BS2000 mainframe operating system. However, the port is a "generic" port insofar as it (I hope) nails down every place in OpenSSL which is ASCII-based (i.e., where assumptions are hardwired into the code which only hold for ASCII platforms). At these code spots, a conversion routine is called to convert between ASCII and EBCDIC. [Internally, the data structures are kept in ASCII form to reduce redundant conversions. Only when the external representation of certificate objects is required, is the respective conversion routine called. Therefore, all checksum operations etc. result in the same values as for a native ascii platform.] All you will need to change for IBM platforms is this: * wait until I submit the patches to the OpenSSL list ;-) * get the IBM EBCDIC-to-ASCII table out of the Apache source code (it differs slightly from the BS2000 EBCDIC table I used) and add it to crypto/ebcdic.c (I might do that myself) * modify config and Configure to detect your machine/platform * Add a #define CHARSET_EBCDIC to the Configuration line for your machine/platform That´s about all. Currently, I'm busy moving to a new house, so bear with me - I don't have the time right now. Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany
[OpenSSL@dcWWW.mch.sni.de: Re: SSLeay EBCDIC]
I tried to Cc this to [EMAIL PROTECTED], but it bounced. I'll re-try with [EMAIL PROTECTED]. You don't happen to use sendmail, do you? Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany On Fri, May 14, 1999 at 05:44:02PM +0200, Louis Kotze wrote: Hi Martin, I am about to embark of porting OpenSSL to the OS/390 platform, as EBCDIC is mainly used for the IBM world, I am curious as to porting you have done and if it is for the OS/390 platform can I get any assistance ? I have not ported to an IBM platform, but to Siemens' own BS2000 mainframe operating system. However, the port is a "generic" port insofar as it (I hope) nails down every place in OpenSSL which is ASCII-based (i.e., where assumptions are hardwired into the code which only hold for ASCII platforms). At these code spots, a conversion routine is called to convert between ASCII and EBCDIC. [Internally, the data structures are kept in ASCII form to reduce redundant conversions. Only when the external representation of certificate objects is required, is the respective conversion routine called. Therefore, all checksum operations etc. result in the same values as for a native ascii platform.] All you will need to change for IBM platforms is this: * wait until I submit the patches to the OpenSSL list ;-) * get the IBM EBCDIC-to-ASCII table out of the Apache source code (it differs slightly from the BS2000 EBCDIC table I used) and add it to crypto/ebcdic.c (I might do that myself) * modify config and Configure to detect your machine/platform * Add a #define CHARSET_EBCDIC to the Configuration line for your machine/platform That´s about all. Currently, I'm busy moving to a new house, so bear with me - I don't have the time right now. Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany
[BUG] Extra '}' in Configure Rev. 1.65 line 633
The Rev. 1.65 patch broke Configure. 1.64 was okay. Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[BUG] Missing $ on loop variable at ./util/mklink.pl line 27
Perl 5.0pl3 chokes on the "foreach my $dirname" construct in lines 27 and 48 of mklink.pl Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BN_ULLONG undefined: why?
When compiling OpenSSL (current) and defining SIXTY_FOUR_BIT, the preprocessor define BN_ULLONG is undefined (see comment in file include/bn.h line 119). That results in an error when compiling crypto/bn/bn_div.c: bn_div.c 215: [error]: CFE1020 Identifier "BN_ULLONG" not defined etc. Why is BN_ULLONG undefined in the first place? OTOH, un-commenting it doesn't help either: I get all kinds of warnings that the number of bits in a shift operation is too big, and finally bn_asm bails out with: bn_asm.c 741: [error]: CFE1020 Identifier "BN_MASK" not defined Martin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RC5 in OpenSSL 3 times slower than SSLeay ?!?!
Hello, On one of my machines, the results of comparing SSLeay-0.9.0b against OpenSSL-0.9.2b are disappointing: (have a look at the md5, hmac, sha1, rmd160, rc5/32 and cast result lines in the following tables: performance has dropped by a factor of 2.5 ... 4!!! Is there any recent modification which could explain these results? The same compiler and platform was used, and on the (3 processor machine) I ran these tests sequentially first, and parallel on 2 processors to eliminate workload glitches: the results are identical within statistical range. SSLeay 0.9.0b 29-Jun-1998 built on Wed Feb 24 17:23:25 MET 1999 options:bn(32,32) md2(int) rc4(idx,char) des(idx,cisc,4,long) idea(int) blowfish(idx) C flags not available The 'numbers' are in 1000s of bytes per second processed. type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2 5959.7516.53k 22.39k 24.35k 25.10k mdc211.26k 11.92k 11.98k 12.03k 12.01k md5113.70k 450.62k 689.13k 789.35k 824.77k hmac(md5) 48.62k 299.29k 699.56k 1045.03k 1219.15k sha169.84k 318.53k 558.73k 690.60k 737.01k rmd160 48.36k 204.54k 340.13k 406.83k 431.74k rc4220.41k 263.02k 268.63k 270.65k 271.22k des cbc 56.22k 62.38k 63.22k 63.44k 63.44k des ede321.18k 22.07k 22.15k 22.20k 21.39k idea cbc93.88k 114.27k 116.54k 117.18k 117.42k rc2 cbc 50.94k 55.90k 56.35k 56.58k 56.59k rc5-32/12 cbc 270.62k 381.33k 397.84k 402.18k 404.06k blowfish cbc 102.12k 129.45k 134.05k 134.81k 134.70k cast cbc 253.60k 350.96k 362.55k 369.12k 369.61k signverifysign/s verify/s rsa 512 bits 0.7638s 0.0920s 1.3 10.9 rsa 1024 bits 5.1950s 0.3411s 0.2 2.9 rsa 2048 bits 38.3400s 1.3175s 0.0 0.8 signverifysign/s verify/s dsa 512 bits 0.8809s 1.7233s 1.1 0.6 dsa 1024 bits 3.2333s 6.5100s 0.3 0.2 dsa 2048 bits 12.4500s 25.2200s 0.1 0.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - OpenSSL 0.9.2b 22 Mar 1999 built on: Wed Apr 14 11:04:25 MET DST 1999 options:bn(32,32) md2(int) rc4(idx,char) des(idx,cisc,4,long) idea(int) blowfish(idx) compiler: c89 -XLLML -XLLMK -XL -DB_ENDIAN -DTERMIOS -DCHARSET_EBCDIC The 'numbers' are in 1000s of bytes per second processed. type 8 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2 5878.2616.14k 21.55k 23.56k 24.17k mdc210.92k 11.55k 11.64k 11.64k 11.57k md5 47.99k 160.02k 219.06k 241.82k 247.41k hmac(md5) 23.67k 139.11k 300.43k 422.36k 478.32k sha127.88k 136.72k 250.19k 315.27k 342.02k rmd160 15.21k 63.27k 101.88k 120.61k 126.88k rc4221.34k 263.63k 268.28k 270.41k 271.24k des cbc 55.78k 61.83k 62.45k 62.54k 62.60k des ede321.17k 22.07k 22.18k 21.63k 21.99k idea cbc94.91k 113.75k 116.27k 116.95k 116.63k rc2 cbc 50.80k 55.98k 56.53k 56.70k 56.59k rc5-32/12 cbc 102.12k 125.08k 127.91k 124.01k 127.31k blowfish cbc 104.60k 129.92k 133.64k 134.36k 134.70k cast cbc80.88k 93.64k 96.17k 96.52k 96.54k signverifysign/s verify/s rsa 512 bits 0.8855s 0.0999s 1.1 10.0 rsa 1024 bits 5.7550s 0.3461s 0.2 2.9 rsa 2048 bits 39.1400s 1.2362s 0.0 0.8 signverifysign/s verify/s dsa 512 bits 0.9600s 1.1733s 1.0 0.9 dsa 1024 bits 3.2900s 3.9933s 0.3 0.3 dsa 2048 bits 11.5900s 14.2100s 0.1 0.1 Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RC5 in OpenSSL 3 times slower than SSLeay ?!?!
performance has dropped by a factor of 2.5 ... 4!!! Did you use the same compiler flags for both builds? Yes, of course! Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[BUG] in current CVS tree?
I get warnings when compiling a recent snapshot: cc -I.. -I../../include -KPIC -g -DSNI -DTERMIOS -DB_ENDIAN -c v3_conf.c -o v3_conf.o ../../include/x509.h 259: [warning]: CFE1381 extra ";" ignored DECLARE_STACK_OF(X509_ATTRIBUTE); ^ x509v3.h 227: [warning]: CFE1381 extra ";" ignored DECLARE_STACK_OF(POLICYINFO); ^ x509v3.h 228: [warning]: CFE1381 extra ";" ignored DECLARE_ASN1_SET_OF(POLICYINFO); ^ -- plus I get compile errors because the free_string() method returns void, so cannot be used as argument of a return statement: v3_conf.c 323: [error]: CFE1118 a void function may not return a value return ctx-db_meth-free_string(ctx-db, str); ^ v3_conf.c 332: [error]: CFE1118 a void function may not return a value return ctx-db_meth-free_section(ctx-db, section); ^ Am I missing something (like, e.g., an update ;-) ? Martin -- [EMAIL PROTECTED] |Siemens Information and Phone: +49-89-636-46021 |Communication Products FAX: +49-89-636-47816 |81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
INITALISE or INITIALISE or ...!?
Hi,
Without proposing a complete "british english to american english"
change, I still suggest that the typo in the following BIO modules be
fixed (from BIO_R_UNINITALISED to BIO_R_UNINITIALISED -- note
the 'I' after the 'T'). In order to not break backward compatibility,
the #define BIO_R_UNINITALISED is being duplicated to
BIO_R_UNINITIALISED.
Martin
--
[EMAIL PROTECTED] |Siemens Information and
Phone: +49-89-636-46021 |Communication Products
FAX: +49-89-636-47816 |81730 Munich, Germany
Index: crypto/bio/bio.h
===
RCS file: /home/cvs/OpenSSL.Org/crypto/bio/bio.h,v
retrieving revision 1.6
diff -u -r1.6 bio.h
--- bio.h 1999/03/09 03:01:44 1.6
+++ bio.h 1999/04/14 07:54:04
@@ -721,6 +721,7 @@
#define BIO_R_UNABLE_TO_CREATE_SOCKET 118
#define BIO_R_UNABLE_TO_LISTEN_SOCKET 119
#define BIO_R_UNINITALISED 120
+#define BIO_R_UNINITIALISED 120
#define BIO_R_UNSUPPORTED_METHOD121
#define BIO_R_WSASTARTUP122
Index: crypto/bio/bio_err.c
===
RCS file: /home/cvs/OpenSSL.Org/crypto/bio/bio_err.c,v
retrieving revision 1.2
diff -u -r1.2 bio_err.c
--- bio_err.c 1998/12/22 15:04:29 1.2
+++ bio_err.c 1999/04/14 07:54:04
@@ -108,7 +108,7 @@
{BIO_R_UNABLE_TO_BIND_SOCKET ,"unable to bind socket"},
{BIO_R_UNABLE_TO_CREATE_SOCKET ,"unable to create socket"},
{BIO_R_UNABLE_TO_LISTEN_SOCKET ,"unable to listen socket"},
-{BIO_R_UNINITALISED ,"uninitalised"},
+{BIO_R_UNINITIALISED ,"uninitialised"},
{BIO_R_UNSUPPORTED_METHOD,"unsupported method"},
{BIO_R_WSASTARTUP,"wsastartup"},
{0,NULL},
Index: crypto/bio/bio_lib.c
===
RCS file: /home/cvs/OpenSSL.Org/crypto/bio/bio_lib.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 bio_lib.c
--- bio_lib.c 1998/12/21 10:58:53 1.1.1.3
+++ bio_lib.c 1999/04/14 07:54:04
@@ -162,7 +162,7 @@
if (!b-init)
{
- BIOerr(BIO_F_BIO_READ,BIO_R_UNINITALISED);
+ BIOerr(BIO_F_BIO_READ,BIO_R_UNINITIALISED);
return(-2);
}
@@ -200,7 +200,7 @@
if (!b-init)
{
- BIOerr(BIO_F_BIO_WRITE,BIO_R_UNINITALISED);
+ BIOerr(BIO_F_BIO_WRITE,BIO_R_UNINITIALISED);
return(-2);
}
@@ -241,7 +241,7 @@
if (!b-init)
{
- BIOerr(BIO_F_BIO_PUTS,BIO_R_UNINITALISED);
+ BIOerr(BIO_F_BIO_PUTS,BIO_R_UNINITIALISED);
return(-2);
}
@@ -275,7 +275,7 @@
if (!b-init)
{
- BIOerr(BIO_F_BIO_GETS,BIO_R_UNINITALISED);
+ BIOerr(BIO_F_BIO_GETS,BIO_R_UNINITIALISED);
return(-2);
}
