[openssl.org #312] gcc warning in bss_bio.c

[[EMAIL PROTECTED] via RT]

back when I wrote code, I always tried for error & warning free make
results to build confidence in the user community, but I know it is not
always reasonable . . .

southspit# gcc --version
2.95.3
southspit# uname -a
SunOS southspit 5.9 Generic_112233-01 sun4u sparc SUNW,UltraAX-i2
southspit# which gcc
/opt/sfw/bin/gcc
southspit# history

37  cd openssl-0.9.7-beta3
38  ls
39  more INSTALL
40  which perl
41  ./config
42  make
43  make test
44  h
45  make install



gcc -I.. -I../.. -I../../include -DOPENSSL_SYSNAME_ULTRASPARC -fPIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5
-m32 -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W
-DMD5_ASM  -c  bss_bio.c
bss_bio.c: In function `bio_nread':
bss_bio.c:272: warning: overflow in implicit constant conversion
bss_bio.c: In function `bio_nwrite':
bss_bio.c:433: warning: overflow in implicit constant conversion
ar r ../../libcrypto.a bio_lib.o bio_cb.o bio_err.o  bss_mem.o bss_null.o
bss_fd.o  bss_file.o bss_sock.o bss_conn.o  bf_null.o bf_buff.o b_print.o
b_dump.o  b_sock.o bss_acpt.o bf_nbio.o bss_log.o bss_bio.o
/usr/ccs/bin/ranlib ../../libcrypto.a || echo Never mind.

I bet this will probably never be an issue for us, but FYI.

Thanks,

-Bart

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #325] Open SSL on Bug on Win32

[[EMAIL PROTECTED] via RT]

Dear Sir/Madam,

I would like to use your Open SSL 0.9.6 for web project for security
purpose..
These are the Steps we did.

1) Downloaded the files( openssl-engine-0.9.6g.tar.gz and
openssl-0.9.6g.tar.gz ) from http://www.openssl.org/source/
2) Unzipped using Win Ace2.1
3) Installed Perl from http://www.activestate.com/ActivePerl
4) Run Configure:

E:\FMADocs\openssl-engine-0.9.6g> perl Configure VC-WIN32

output:

Configuring for VC-WIN32
IsWindows=1
CC=cl
CFLAG =-DTHREADS  -DDSO_WIN32
EX_LIBS   =
BN_ASM=bn_asm.o
DES_ENC   =des_enc.o fcrypt_b.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =
RMD160_OBJ_ASM=
PROCESSOR =
RANLIB=true
PERL  =perl
THIRTY_TWO_BIT mode
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined

Configured for VC-WIN32.

5)  Run do_ms for VC++

   E:\FMADocs\openssl-engine-0.9.6g>ms\do_ms

Output (End of the last two line):

E:\FMADocs\openssl-engine-0.9.6g>perl util\mkdef.pl 16 ssleay
1>ms\ssleay16.def


E:\FMADocs\openssl-engine-0.9.6g>perl util\mkdef.pl 32 ssleay
1>ms\ssleay32.def

6) Entered following command on the Dos prompt:

--

E:\FMADocs\openssl-engine-0.9.6g>"C:\Program Files\Microsoft Visual
Studio .Net\
VC7\bin\NMAKE" -f ms\ntdll.mak

OutPut(last few lines):

nul
.\apps\testdsa.h
1 $B8D$N%U%!%$%k$r%3%T!<$7$^$7$?!#(B
copy nul+ .\apps\testrsa.h tmp32\testrsa.h
nul
.\apps\testrsa.h
1 $B8D$N%U%!%$%k$r%3%T!<$7$^$7$?!#(B
cl /Fotmp32\cryptlib.obj  -Iinc32 -Itmp32 /MD /W3 /WX /G5 /Ox
/O2 /Ob2 /
Gs0 /GF /Gy /nologo -DWIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32
-DWINNT
 /Fdout32  -c .\crypto\cryptlib.c
'cl' $B$O!"FbIt%3%^%s%I$^$?$O30It%3%^%s%I!"(B
$BA`:n2DG=$J%W%m%0%i%`$^$?$O%P%C%A(B $B%U%!%$%k$H$7$FG'<1$5$l$F$$$^$;$s!#(B

(This message is displayed in Japanese, but translated into english i.e.,
Internal command or external command or program or batch file of cl
program is not recognize)

NMAKE : fatal error U1077: 'cl' : return code '0x1'
Stop.
E:\FMADocs\openssl-engine-0.9.6g>
---

Please give me the suggestions for above error message...

Environment:

OpenSSL version: output of 'openssl 0.9.6.g'
OS Name:   Windows 2000 Professional,
Hardware platform: Petium4, 256Mb RAM, 1.5GH processror
Compiler Details:  VC++ Compiler
  Application Details: Visual Studio 6 and Visual Studio .net

Awaiting for your reply..

Thanks & Regards
Surya

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #184] OpenVMS openssl-0.9.7-beta3.tar.gz

[[EMAIL PROTECTED] via RT]

I'll try and get to it some time this weekend Richard.

>Mark,
>
>I'm sorry, I can't quite remember where this went.  I'm pretty sure 
>part if the issues in this mail were solved as a result of another 
>ticket, but I haven't yet looked into the issue with 
>SSL_CIPHER_get...().  Could you do me the favor of downloading the 
>latest 0.9.7 snapshot and give it a try?
>
>[[EMAIL PROTECTED] - Thu Aug  1 09:03:44 2002]:
>
>> Hi (probably) Richard,
>> 
>>   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
>>   on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3
>>   Compaq C V6.5-001 on OpenVMS Alpha V7.3
>> 
>> has some minor issues for me (hope it's still intelligable).
>> 
>> 
>~~~
>> 
>> Compiling The CA.C File.
>> 
>> if (!strcasecmp(rev_arg, crl_reasons[i]))
>> .^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp"
>> is implicitly declared as a function.
>> at line number 2878 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]CA.C;1
>> 
>> 
>> Compiling The SPEED.C File.
>> 
>> printf("HZ=%g", (double)HZ);
>> ^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "sysconf"
>> is implicitly declared as a function.
>> at line number 1630 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]SPEED.C;1
>> Compiling The S_TIME.C File.
>> Compiling The APPS.C File.
>> 
>> if (!strcasecmp(arg, "none"))
>> .^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp"
>> is implicitly declared as a function.
>> at line number 1123 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]APPS.C;1
>> 
>> 
>> 
>~~~
>> 
>> Also one major issue ... the following code works in all versions
>>prior
>> to 0.9.7b3 (including 0.9.6e).  With 0.9.7b3 it returns a 'Total' 
>of 1
>> which SS_CIPHER_get..() returns a string of "(NONE)".  Can you 
>tell me
>> whether my original code is broken and 0.9.7 is just revealing 
>this or
>> is it a toolkit problem?
>> 
>> 
>~~~
>> 
>>   /* this is the service's cipher list - not the current 
>session's! */
>>   StackPtr = SslCtx->cipher_list;
>> 
>>   Total = sk_num (StackPtr);
>>   for (Count = 0; Count < Total; Count++)
>>   {
>>  CipherPtr = (SSL_CIPHER *)sk_value (StackPtr, Count);
>> 
>>  vecptr = FaoVector;
>>  *vecptr++ = Count + 1;
>>  *vecptr++ = SSL_CIPHER_get_version (CipherPtr);
>>  *vecptr++ = SSL_CIPHER_get_name (CipherPtr);
>> 
>>  status = NetWriteFaol (rqptr, CiphersFao, &FaoVector);
>>  if (VMSnok (status))
>> ErrorNoticed (status, "NetWriteFaol()",   FI_LI);
>>   }
>> 
>> 
>~~~
>> 
>> Regards, Mark.
>> 
>> 
>++
>>  Mark Daniel 
>http://wasd.vsm.com.au/adelaide
>>  mailto:Mark.Daniel@;wasd.vsm.com.au 
>([EMAIL PROTECTED])
>> 
>++
>> 
>
>
>-- 
>Richard Levitte

Regards,

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:Mark.Daniel@;wasd.vsm.com.au ([EMAIL PROTECTED])
++

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #184] OpenVMS openssl-0.9.7-beta3.tar.gz

[[EMAIL PROTECTED] via RT]

I'll try and get to it some time this weekend Richard.

>Mark,
>
>I'm sorry, I can't quite remember where this went.  I'm pretty sure 
>part if the issues in this mail were solved as a result of another 
>ticket, but I haven't yet looked into the issue with 
>SSL_CIPHER_get...().  Could you do me the favor of downloading the 
>latest 0.9.7 snapshot and give it a try?
>
>[[EMAIL PROTECTED] - Thu Aug  1 09:03:44 2002]:
>
>> Hi (probably) Richard,
>> 
>>   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
>>   on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3
>>   Compaq C V6.5-001 on OpenVMS Alpha V7.3
>> 
>> has some minor issues for me (hope it's still intelligable).
>> 
>> 
>~~~
>> 
>> Compiling The CA.C File.
>> 
>> if (!strcasecmp(rev_arg, crl_reasons[i]))
>> .^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp"
>> is implicitly declared as a function.
>> at line number 2878 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]CA.C;1
>> 
>> 
>> Compiling The SPEED.C File.
>> 
>> printf("HZ=%g", (double)HZ);
>> ^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "sysconf"
>> is implicitly declared as a function.
>> at line number 1630 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]SPEED.C;1
>> Compiling The S_TIME.C File.
>> Compiling The APPS.C File.
>> 
>> if (!strcasecmp(arg, "none"))
>> .^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp"
>> is implicitly declared as a function.
>> at line number 1123 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]APPS.C;1
>> 
>> 
>> 
>~~~
>> 
>> Also one major issue ... the following code works in all versions
>>prior
>> to 0.9.7b3 (including 0.9.6e).  With 0.9.7b3 it returns a 'Total' 
>of 1
>> which SS_CIPHER_get..() returns a string of "(NONE)".  Can you 
>tell me
>> whether my original code is broken and 0.9.7 is just revealing 
>this or
>> is it a toolkit problem?
>> 
>> 
>~~~
>> 
>>   /* this is the service's cipher list - not the current 
>session's! */
>>   StackPtr = SslCtx->cipher_list;
>> 
>>   Total = sk_num (StackPtr);
>>   for (Count = 0; Count < Total; Count++)
>>   {
>>  CipherPtr = (SSL_CIPHER *)sk_value (StackPtr, Count);
>> 
>>  vecptr = FaoVector;
>>  *vecptr++ = Count + 1;
>>  *vecptr++ = SSL_CIPHER_get_version (CipherPtr);
>>  *vecptr++ = SSL_CIPHER_get_name (CipherPtr);
>> 
>>  status = NetWriteFaol (rqptr, CiphersFao, &FaoVector);
>>  if (VMSnok (status))
>> ErrorNoticed (status, "NetWriteFaol()",   FI_LI);
>>   }
>> 
>> 
>~~~
>> 
>> Regards, Mark.
>> 
>> 
>++
>>  Mark Daniel 
>http://wasd.vsm.com.au/adelaide
>>  mailto:[EMAIL PROTECTED] 
>([EMAIL PROTECTED])
>> 
>++
>> 
>
>
>-- 
>Richard Levitte

Regards,

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #184] OpenVMS openssl-0.9.7-beta3.tar.gz

[[EMAIL PROTECTED] via RT]

Hi Richard,

>I'm sorry, I can't quite remember where this went.  I'm pretty sure 
>part if the issues in this mail were solved as a result of another 
>ticket, but I haven't yet looked into the issue with 
>SSL_CIPHER_get...().  Could you do me the favor of downloading the 
>latest 0.9.7 snapshot and give it a try?

Currently using ...

  Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
  on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3-1
  Compaq C V6.5-001 on OpenVMS Alpha V7.3-1

Already had

  http://www.openssl.org/source/openssl-0.9.7-beta3.tar.gz

so I deleted all .OBJ, .OLB and .EXE and rebuilt it.

Yep same issues ...


Compiling The CA.C File.

if (!strcasecmp(rev_arg, crl_reasons[i]))
.^
%CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp" is
implicitly
 declared as a function.
at line number 2878 in file
HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]CA.C;1
Compiling The PKCS7.C File.
.
.
.
Compiling The SPEED.C File.

printf("HZ=%g", (double)HZ);
^
%CC-I-IMPLICITFUNC, In this statement, the identifier "sysconf" is
implicitly de
clared as a function.
at line number 1630 in file
HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]SPEED.C;1
Compiling The S_TIME.C File.
Compiling The APPS.C File.

if (!strcasecmp(arg, "none"))
.^
%CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp" is
implicitly
 declared as a function.
at line number 1123 in file
HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]APPS.C;1
Compiling The S_CB.C File.


Passed all @[.TEST]TESTS.COM (no errors reported anyway).

WASD package compiles against it OK and runs OK.

The problem with the cipher list must have been my original clumsy code.
I reworked it (according to my change log)

  11-AUG-2002  MGD  refine SesolaReport() for obtaining service ciphers
(OpenSSLv0.9.6f/0.9.7-beta break it),
built and tested against CPQ AXPVMS SSL V1.0-A,
internal PEM cert/key as fallback; mainly for VMS
(Open)SSL

Regards, Mark.

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

>[[EMAIL PROTECTED] - Thu Aug  1 09:03:44 2002]:
>
>> Hi (probably) Richard,
>> 
>>   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
>>   on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3
>>   Compaq C V6.5-001 on OpenVMS Alpha V7.3
>> 
>> has some minor issues for me (hope it's still intelligable).
>> 
>> 
>~~~
>> 
>> Compiling The CA.C File.
>> 
>> if (!strcasecmp(rev_arg, crl_reasons[i]))
>> .^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp"
>> is implicitly declared as a function.
>> at line number 2878 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]CA.C;1
>> 
>> 
>> Compiling The SPEED.C File.
>> 
>> printf("HZ=%g", (double)HZ);
>> ^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "sysconf"
>> is implicitly declared as a function.
>> at line number 1630 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]SPEED.C;1
>> Compiling The S_TIME.C File.
>> Compiling The APPS.C File.
>> 
>> if (!strcasecmp(arg, "none"))
>> .^
>> %CC-I-IMPLICITFUNC, In this statement, the identifier "strcasecmp"
>> is implicitly declared as a function.
>> at line number 1123 in file
>> HT_ROOT:[SRC.OPENSSL-0_9_7-BETA3.APPS]APPS.C;1
>> 
>> 
>> 
>~~~
>> 
>> Also one major issue ... the following code works in all versions
>>prior
>> to 0.9.7b3 (including 0.9.6e).  With 0.9.7b3 it returns a 'Total' 
>of 1
>> which SS_CIPHER_get..() returns a string of "(NONE)".  Can you 
>tell me
>> whether my original code is broken and 0.9.7 is just revealing 
>this or
>> is it a toolkit problem?
>> 
>> 
>~~~
>> 
>>   /* this is the service's cipher list - not the current 
>session's! */
>>   StackPtr = SslCtx->cipher_list;
>> 
>>   Total = sk_num (StackPtr);
>>   for (Count = 0; Count < Total; Count++)
>>   {
>>  CipherPtr = (SSL_CIPHER *)sk_value (StackPtr, Count);
>> 
>>  vecptr = FaoVector;
>>  *vecptr++ = Count + 1;
>>  *vecptr++ = SSL_CIPHER_get_version (CipherPtr);
>>  *vecptr++ = SSL_CIPHER_get_name (CipherPtr);
>> 
>>  status = NetWriteFaol (rqptr, CiphersFao, &FaoVector);
>>  if (VMSnok (status))
>> ErrorNoticed (status, "NetWriteFaol()", 

RE: [openssl.org #184] OpenVMS openssl-0.9.7-beta3.tar.gz

[[EMAIL PROTECTED] via RT]

OK, didn't know about that area.

Currently using ...
 
   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
   on a AlphaServer 1200 5/533 4MB running OpenVMS V7.3-1
   Compaq C V6.5-001 on OpenVMS Alpha V7.3-1
 
One issue ...


Compiling The SPEED.C File.

printf("HZ=%g", (double)HZ);
^
%CC-I-IMPLICITFUNC, In this statement, the identifier "sysconf" is
implicitly de
clared as a function.
at line number 1630 in file
HT_ROOT:[SRC.OPENSSL-0_9_7-STABLE-SNAP-20021117.APPS
]SPEED.C;1
Compiling The S_TIME.C File.


@[TEST]TESTS.COM ok.

WASD SSL compiles against it OK.  Server runs with it OK (still reports
itself as "OpenSSL 0.9.7-beta3 30 Jul 2002").

Regards, Mark.

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #347] DJGPP patch for openssl-0.9.7

[[EMAIL PROTECTED] via RT]

The following patch allows openssl-0.9.7 to compile under DJGPP. The
process was broken by two recent changes. Gisle's patch left out
some required headers. The changes for Cygwin added PATH directives
incompatible with the DJGPP path separator of ";" rather than ":".

In addition there seems to be an error in ectest.c. That file is run
from the "test" subdirectory. The "FLAT_INC" portion of the code
doesn't work under DJGPP, and I am not sure how it would under other
platforms (referring to "../.." when it is one directory under the top
directory). None of the other test files which include  use
this construction. I would think that either all need it, or none of
them.

I also changed INSTALL.DJGPP to reflect the need to put WATT_ROOT in
the environment prior to configuring.

I am attaching the patch, since it has long lines that would get
munged in the archives. Since I am in the US, I am also sending a copy
to the US government site. With the new regulations, it doesn't appear
that I can just send a copy of this email. Look for a copy of my
notification in openssl-dev with subject "TSU Request - encryption".

The patch is against the 20001115 snapshot. After applying tha patch,
there are no warnings with "make depend, make, make test, or make
install". This was only tested with "Configure no-threads no-idea no-rc5
no-mdc2 386 --prefix=/dev/env/DJDIR DJGPP".
   Doug

__
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #356] Bug in CRLF translation in PKCS7_sign

[[EMAIL PROTECTED] via RT]

OS: Windows, but I think it is a cross-platform bug.
Version: 0.9.6g

In the following function which is called from
PKCS7_sign, if the source text contains a line of text
which is exactly a mutiple of MAX_SMLEN-2 characters
long and has a CRLF line ending, then the gets call
will return a buffer which ends with just a CR, and
then on the next call a line that contains just an LF,
which will result in two CRLF pairs being put into the
output.

A harmless bit of buggy coding is also present.  The
value of len is not checked in the inner while loop. 
Any line which only contains CR or LF characters will
cause len to go to 0, and the memory location
linebuf[-1] will be read.  Its extremely unlikely that
the value at that location is a CR or LF, so usually
the loop terminates anyway.  But, its not nice to go
out of bounds, and I imagine memory protection faults
could be triggered on some platforms.

This only affects callers who do not pass PKCS7_BINARY
in the flags parameter (our work-around was to
normalize the line endings ourselves and then pass
PKCS7_BINARY).

/* Copy text from one BIO to another making the output
CRLF at EOL */
int SMIME_crlf_copy(BIO *in, BIO *out, int flags)
{
char eol;
int len;
char linebuf[MAX_SMLEN];
if(flags & PKCS7_BINARY) {
while((len = BIO_read(in, linebuf, MAX_SMLEN)) > 0)
BIO_write(out, linebuf, len);
return 1;
}
if(flags & PKCS7_TEXT) BIO_printf(out, "Content-Type:
text/plain\r\n\r\n");
while ((len = BIO_gets(in, linebuf, MAX_SMLEN)) > 0)
{
eol = 0;
while(iscrlf(linebuf[len - 1])) {
len--;
eol = 1;
}   
BIO_write(out, linebuf, len);
if(eol) BIO_write(out, "\r\n", 2);
}
return 1;
}

--Peter Lincroft



__
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #358] patch for openssl-SNAP-20021120. Attempt to improve configurability.

[[EMAIL PROTECTED] via RT]

Hi,

This patch makes it possible to build apps/openssl without the speed
and ocsp programs and without sockets.

to disable apps/speed.c (openssl speed) just Configure with no-speed.

Thank you,
Enrique 

diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-20021120/apps/ocsp.c ./apps/ocsp.c
--- /tmp/openssl-SNAP-20021120/apps/ocsp.c  2002-11-13 17:00:24.0 +0100
+++ ./apps/ocsp.c   2002-11-22 04:00:56.0 +0100
@@ -55,6 +55,7 @@
  * Hudson ([EMAIL PROTECTED]).
  *
  */
+#ifndef OPENSSL_NO_OCSP
 
 #include 
 #include 
@@ -722,7 +723,12 @@
}
else if (host)
{
+#ifndef OPENSSL_NO_SOCK
cbio = BIO_new_connect(host);
+#else
+   BIO_printf(bio_err, "Error creating connect BIO - sockets not 
+supported.\n");
+   goto end;
+#endif
if (!cbio)
{
BIO_printf(bio_err, "Error creating connect BIO\n");
@@ -1139,7 +1145,11 @@
bufbio = BIO_new(BIO_f_buffer());
if (!bufbio) 
goto err;
+#ifndef OPENSSL_NO_SOCK
acbio = BIO_new_accept(port);
+#else
+  BIO_printf(bio_err, "Error setting up accept BIO - sockets not supported.\n");
+#endif
if (!acbio)
goto err;
BIO_set_accept_bios(acbio, bufbio);
@@ -1226,3 +1236,4 @@
return 1;
}
 
+#endif
diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-20021120/apps/progs.h ./apps/progs.h
--- /tmp/openssl-SNAP-20021120/apps/progs.h 2002-08-26 14:00:21.0 +0200
+++ ./apps/progs.h  2002-11-22 04:01:11.0 +0100
@@ -100,7 +100,9 @@
 #if !defined(OPENSSL_NO_SOCK) && !(defined(OPENSSL_NO_SSL2) && 
defined(OPENSSL_NO_SSL3))
{FUNC_TYPE_GENERAL,"s_client",s_client_main},
 #endif
+#ifndef OPENSSL_NO_SPEED
{FUNC_TYPE_GENERAL,"speed",speed_main},
+#endif
 #if !defined(OPENSSL_NO_SOCK) && !(defined(OPENSSL_NO_SSL2) && 
defined(OPENSSL_NO_SSL3))
{FUNC_TYPE_GENERAL,"s_time",s_time_main},
 #endif
@@ -120,7 +122,9 @@
{FUNC_TYPE_GENERAL,"smime",smime_main},
{FUNC_TYPE_GENERAL,"rand",rand_main},
{FUNC_TYPE_GENERAL,"engine",engine_main},
+#ifndef OPENSSL_NO_OCSP
{FUNC_TYPE_GENERAL,"ocsp",ocsp_main},
+#endif
 #ifndef OPENSSL_NO_MD2
{FUNC_TYPE_MD,"md2",dgst_main},
 #endif
diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-20021120/apps/speed.c ./apps/speed.c
--- /tmp/openssl-SNAP-20021120/apps/speed.c 2002-11-19 01:00:57.0 +0100
+++ ./apps/speed.c  2002-11-21 23:33:02.0 +0100
@@ -71,6 +71,8 @@
 
 /* most of this code has been pilfered from my libdes speed.c program */
 
+#ifndef OPENSSL_NO_SPEED
+
 #undef SECONDS
 #define SECONDS3   
 #define RSA_SECONDS10
@@ -2569,3 +2571,4 @@
return 1;
}
 #endif
+#endif
diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-20021120/crypto/x509v3/ext_dat.h 
./crypto/x509v3/ext_dat.h
--- /tmp/openssl-SNAP-20021120/crypto/x509v3/ext_dat.h  2002-06-13 15:00:47.0 
+0200
+++ ./crypto/x509v3/ext_dat.h   2002-11-22 09:33:10.0 +0100
@@ -90,17 +90,23 @@
 &v3_crld,
 &v3_ext_ku,
 &v3_crl_reason,
+#ifndef OPENSSL_NO_OCSP
 &v3_crl_invdate,
+#endif
 &v3_sxnet,
 &v3_info,
+#ifndef OPENSSL_NO_OCSP
 &v3_ocsp_nonce,
 &v3_ocsp_crlid,
 &v3_ocsp_accresp,
 &v3_ocsp_nocheck,
 &v3_ocsp_acutoff,
 &v3_ocsp_serviceloc,
+#endif
 &v3_sinfo,
+#ifndef OPENSSL_NO_OCSP
 &v3_crl_hold
+#endif
 };
 
 /* Number of standard extensions */
diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-20021120/crypto/x509v3/v3_ocsp.c 
./crypto/x509v3/v3_ocsp.c
--- /tmp/openssl-SNAP-20021120/crypto/x509v3/v3_ocsp.c  2001-02-23 05:01:03.0 
+0100
+++ ./crypto/x509v3/v3_ocsp.c   2002-11-22 09:33:03.0 +0100
@@ -56,6 +56,8 @@
  *
  */
 
+#ifndef OPENSSL_NO_OCSP
+
 #include 
 #include "cryptlib.h"
 #include 
@@ -270,3 +272,4 @@
 err:
return 0;
}
+#endif
diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-20021120/ssl/bio_ssl.c 
./ssl/bio_ssl.c
--- /tmp/openssl-SNAP-20021120/ssl/bio_ssl.c2002-01-12 17:00:41.0 +0100
+++ ./ssl/bio_ssl.c 2002-11-21 23:06:11.0 +0100
@@ -526,6 +526,7 @@
 
 BIO *BIO_new_ssl_connect(SSL_CTX *ctx)
{
+#ifndef OPENSSL_NO_SOCK
BIO *ret=NULL,*con=NULL,*ssl=NULL;
 
if ((con=BIO_new(BIO_s_connect())) == NULL)
@@ -538,6 +539,7 @@
 err:
if (con != NULL) BIO_free(con);
if (ret != NULL) BIO_free(ret);
+#endif
return(NULL);
}
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #358] patch for openssl-SNAP-20021120. Attempt to improve configurability.

[[EMAIL PROTECTED] via RT]

Hi,

I am working on trying to build the libraries (libcrypto and libssl) to
run on an embedded system with limited storage. To give you an idea, i have
approximately 1.5 megabytes of diskspace in the system. I need to reduce the
footprint of the libraries as much as possible.  

We dont plan to use OCSP in our system. This is the reason we want to turn
it off and save space. Although the gain (in this specific case) is small
regarding to footprint the idea of having a configurable library is in my
opinion good. 

apps/openssl is used by some of the test scripts in the test directory. I
need to be able to run the tests to verify that I have a working library.
This is why patches for the apps/ are provided to.

BTW, if you have any suggestions, it may be config options, stuff in the
TODO lists or anything that may help reduce the footprint of the library 
please let me know.

Thank you,
Enrique


On Tue, Nov 26, 2002 at 10:39:33AM +0100, Richard Levitte via RT wrote:
> 
> I can understand wanting to disable the use of sockets.  I can't 
> understand why OCSP or speed should be disabled, however.  Please 
> explain.
> 
> [[EMAIL PROTECTED] - Sat Nov 23 19:46:14 2002]:
> 
> > Hi,
> > 
> > This patch makes it possible to build apps/openssl without the 
> speed
> > and ocsp programs and without sockets.
> > 
> > to disable apps/speed.c (openssl speed) just Configure with 
> no-speed.
> > 
> > Thank you,
> > Enrique
> > 
> > diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
> >20021120/apps/ocsp.c ./apps/ocsp.c
> > --- /tmp/openssl-SNAP-20021120/apps/ocsp.c  2002-11-13
> >17:00:24.0 +0100
> > +++ ./apps/ocsp.c   2002-11-22 04:00:56.0 +0100
> > @@ -55,6 +55,7 @@
> >   * Hudson ([EMAIL PROTECTED]).
> >   *
> >   */
> > +#ifndef OPENSSL_NO_OCSP
> > 
> >  #include 
> >  #include 
> > @@ -722,7 +723,12 @@
> > }
> > else if (host)
> > {
> > +#ifndef OPENSSL_NO_SOCK
> > cbio = BIO_new_connect(host);
> > +#else
> > +   BIO_printf(bio_err, "Error creating connect
> >BIO - sockets not supported.\n");
> > +   goto end;
> > +#endif
> > if (!cbio)
> > {
> > BIO_printf(bio_err, "Error creating connect
> >BIO\n");
> > @@ -1139,7 +1145,11 @@
> > bufbio = BIO_new(BIO_f_buffer());
> > if (!bufbio)
> > goto err;
> > +#ifndef OPENSSL_NO_SOCK
> > acbio = BIO_new_accept(port);
> > +#else
> > +  BIO_printf(bio_err, "Error setting up accept BIO - sockets not
> >supported.\n");
> > +#endif
> > if (!acbio)
> > goto err;
> > BIO_set_accept_bios(acbio, bufbio);
> > @@ -1226,3 +1236,4 @@
> > return 1;
> > }
> > 
> > +#endif
> > diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
> >20021120/apps/progs.h ./apps/progs.h
> > --- /tmp/openssl-SNAP-20021120/apps/progs.h 2002-08-26
> >14:00:21.0 +0200
> > +++ ./apps/progs.h  2002-11-22 04:01:11.0 +0100
> > @@ -100,7 +100,9 @@
> >  #if !defined(OPENSSL_NO_SOCK) && !(defined(OPENSSL_NO_SSL2) &&
> >defined(OPENSSL_NO_SSL3))
> > {FUNC_TYPE_GENERAL,"s_client",s_client_main},
> >  #endif
> > +#ifndef OPENSSL_NO_SPEED
> > {FUNC_TYPE_GENERAL,"speed",speed_main},
> > +#endif
> >  #if !defined(OPENSSL_NO_SOCK) && !(defined(OPENSSL_NO_SSL2) &&
> >defined(OPENSSL_NO_SSL3))
> > {FUNC_TYPE_GENERAL,"s_time",s_time_main},
> >  #endif
> > @@ -120,7 +122,9 @@
> > {FUNC_TYPE_GENERAL,"smime",smime_main},
> > {FUNC_TYPE_GENERAL,"rand",rand_main},
> > {FUNC_TYPE_GENERAL,"engine",engine_main},
> > +#ifndef OPENSSL_NO_OCSP
> > {FUNC_TYPE_GENERAL,"ocsp",ocsp_main},
> > +#endif
> >  #ifndef OPENSSL_NO_MD2
> > {FUNC_TYPE_MD,"md2",dgst_main},
> >  #endif
> > diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
> >20021120/apps/speed.c ./apps/speed.c
> > --- /tmp/openssl-SNAP-20021120/apps/speed.c 2002-11-19
> >01:00:57.0 +0100
> > +++ ./apps/speed.c  2002-11-21 23:33:02.0 +0100
> > @@ -71,6 +71,8 @@
> > 
> >  /* most of this code has been pilfered from my libdes speed.c 
> program
> >*/
> > 
> > +#ifndef OPENSSL_NO_SPEED
> > +
> >  #undef SECONDS
> >  #define SECONDS3
> >  #define RSA_SECONDS10
> > @@ -2569,3 +2571,4 @@
> > return 1;
> > }
> >  #endif
> > +#endif
> > diff --exclude=Makefile.ssl -rbu /tmp/openssl-SNAP-
> >20021120/crypto/x509v3/ext_dat.h ./crypto/x509v3/ext_dat.h
> > --- /tmp/openssl-SNAP-20021120/crypto/x509v3/ext_dat.h  2002-06-13
> >15:00:47.0 +0200
> > +++ ./crypto/x509v3/ext_dat.h   2002-11-22 09:33:10.0 +0100
> > @@ -90,17 +90,23 @@
> >  &v3_crld,
> >  &v3_ext_ku,
> >  &v3_crl_reason,
> > +#ifndef OPENSSL_NO_OCSP
> >  &v3_crl_invdate,
> > +#endif
> >  &v3_sxnet,
> >  &v3_info,
> > +#ifndef OPENSSL_

[openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz

[[EMAIL PROTECTED] via RT]

Hi Richard,

BETA 4 good news ... and bad.

Builds, tests and works OK with WASD on

  Compaq C V6.5-001 on OpenVMS Alpha V7.3-1
  Compaq TCP/IP Services for OpenVMS Alpha Version V5.3
  on a Digital AlphaStation 500/333 running OpenVMS V7.3-1

Builds OK on 

  Compaq C V6.4-005 on OpenVMS VAX V7.3
  Compaq TCP/IP Services for OpenVMS VAX Version V5.3
  on a VAXstation 4000-60 running OpenVMS V7.3
 
but fails (actually never seems to complete) one of the tests.  Here's the relevant 
portion (hope it's not too distorted).


Generate and verify a certificate request
generating certificate request
There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
Generating a 512 bit RSA private key















...
VIXEN::_FTA10: 19:17:50 OPENSSL   CPU=00:36:33.64 PF=229160 IO=158952 MEM=3316
VIXEN::_FTA10: 19:17:53 OPENSSL   CPU=00:36:36.12 PF=229162 IO=158953 MEM=3318
VIXEN::_FTA10: 19:17:55 OPENSSL   CPU=00:36:38.42 PF=229162 IO=158954 MEM=3318















...
VIXEN::_FTA10: 19:26:57 OPENSSL   CPU=00:45:29.66 PF=232131 IO=160231 MEM=4175
VIXEN::_FTA10: 19:26:58 OPENSSL   CPU=00:45:30.56 PF=232134 IO=160232 MEM=4178
VIXEN::_FTA10: 19:26:59 OPENSSL   CPU=00:45:32.17 PF=232134 IO=160233 MEM=4178
VIXEN::_FTA10: 19:27:00 OPENSSL   CPU=00:45:33.08 PF=232134 IO=160234 MEM=4178
VIXEN::_FTA10: 19:27:01 OPENSSL   CPU=00:45:34.07 PF=232134 IO=160235 MEM=4178
 Interrupt

testing req conversions
%CONV-F-OPENIN, error opening HT_ROOT:[SRC.OPENSSL-0_9_7-BETA4.TEST]TESTREQ.PEM;
 as input
-RMS-E-FNF, file not found
VIXEN$ shd
  HT_ROOT:[SRC.OPENSSL-0_9_7-BETA4.TEST]
VIXEN$


Also, when WASD linked is linked to it and an SSL service accessed the browser reports

  10.1.1.3 received a message with incorrect Message Authentication
  Code.  If the error occurs frequesntly contact the website
  administrator.

This is the case whether the build is done using

USER_CCDEFS == "_VMS_V6_SOURCE=1,__VMS_VER=6000,__CRTL_VER=600"

or not (I've tried both).

Just to repeat - OK on Alpha, problems on VAX.

Sorry, Mark.

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

_

RE[2]: [openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz

[[EMAIL PROTECTED] via RT]

I didn't try the VAX version (that I can remember - but it's not on my
home VAXstation system so I'd say not).  I could grab it tomorrow and
try.

Regards, Mark.

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

>
>In message <[EMAIL PROTECTED]> on Wed, 27 Nov 2002 12:56:16 
>+0100 (MET), "[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]> said:
>
>rt> Builds OK on 
>rt> 
>rt>   Compaq C V6.4-005 on OpenVMS VAX V7.3
>rt>   Compaq TCP/IP Services for OpenVMS VAX Version V5.3
>rt>   on a VAXstation 4000-60 running OpenVMS V7.3
>rt>  
>rt> but fails (actually never seems to complete) one of the tests.  Here's the 
>relevant portion (hope it's not too distorted).
>rt> 
>rt> 
>rt> Generate and verify a certificate request
>rt> generating certificate request
>rt> There should be a 2 sequences of .'s and some +'s.
>rt> There should not be more that at most 80 per line
>rt> This could take some time.
>rt> Generating a 512 bit RSA private key
>rt> 
>[...]
>
>Did this work with beta 3?
>
>-- 
>Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
>Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
>\  SWEDEN   \ or +46-708-26 53 44
>Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
>Member of the OpenSSL development team: http://www.openssl.org/
>
>Unsolicited commercial email is subject to an archival fee of $400.
>See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz

[[EMAIL PROTECTED] via RT]

Hi Richard,

It seems as if you have answered your own earlier suggestion to me.  I
can confirm this.  With OPSNSSL_NO_ASM defined true BETA 4 builds, tests
and works with WASD OK for me too.

I was working my way back down the BETAs, 4 -> 3 -> 2 ..., looking for
one that would work, when I read you ASM email.  I went back to 4 and
the above is the result.  One of the issues with my tired old VAXstation
4000/60 is that each build and test run takes many hours.

Regards, Mark.

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

>
>[levitte - Fri Nov 29 17:31:16 2002]:
>
>> Another question: have you tried defining the logical name
>> OPENSSL_NO_ASM with the value YES before building?  If you build it
>> that way, it should work.  I'm assuming the problem lies in
>> [.CRYPTO.BN.ASM]VMS.MAR, and if you can verify that it runs all
>> tests correctly when OPENSSL_NO_ASM if defined, it will definitely
>> narrow down the space I need to look into.
>
>Confirmed, it's the assembler version of bn_div_words that doesn't 
>work for some values, basically when the quotient gets the high bit 
>set.  The reason is that EDIV treats that as an integer overflow, 
>since the beginning of the routine makes sure all arguments to EDIV 
>are positive (i.e. don't have the high bit set).  The result in such 
>cases is that the quotient really is the remainder, and we get 
>whacked result.
>
>An example:
>
>bn_div_words(57DEDEDE,DEC0003F,8000) -> 6F60001F
>
>because EDIV is be handed this (the numbers are different because 
>everything is shifted down one step to make sure all numbers are 
>positive):
>
>2BEF6F6F6F60001F as dividend
>4000 as divisor
>
>Making the operation 2BEF6F6F6F60001F / 4000 result in the 
>quotient AFBDBDBD, which is signed, and therefore makes EDIV think 
>it's an error since that's a negative number...
>
>I'm starting to believe that the divisor doesn't really need to get 
>shifted at all, which would simplify the fiddling, and deal with the 
>kind of situation that gets us the current bug.  I'll do some 
>research in the next few days.  If I don't get it in time for 
>0.9.7-beta5, I'll simply revert to the routines that worked (the 
>0.9.6 ones).
>
>-- 
>Richard Levitte

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE[2]: [openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz

[[EMAIL PROTECTED] via RT]

Hi Richard,

happy to try the attached file ... as soon as you attach it!

(with neither email :^)

Regards, Mark.

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

>Return-path: <[EMAIL PROTECTED]>
>Received: from serv01.aet.tu-cottbus.de ([141.43.132.161])
> by vsm.com.au (PMDF V6.1-1 #39212)
> with ESMTP id <[EMAIL PROTECTED]> for [EMAIL PROTECTED]
> (ORCPT [EMAIL PROTECTED]); Sun, 01 Dec 2002 12:47:39 +1030
>Received: from localhost (localhost [127.0.0.1])   by serv01.aet.tu-cottbus.de
> (Postfix) with ESMTP  id D7FC63330; Sun, 01 Dec 2002 03:17:34 +0100 (MET)
>Received: by serv01.aet.tu-cottbus.de (Postfix, from userid 29994)
> id 75BF03336; Sun, 01 Dec 2002 03:17:31 +0100 (MET)
>Date: Sun, 01 Dec 2002 03:17:31 +0100 (MET)
>From: Richard Levitte - VMS Whacker via RT <[EMAIL PROTECTED]>
>Subject: Re: [openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz
>In-reply-to: <[EMAIL PROTECTED]>
>Sender: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Reply-to: [EMAIL PROTECTED]
>Message-id: <[EMAIL PROTECTED]>
>MIME-version: 1.0
>X-Mailer: Perl5 Mail::Internet v1.33
>Content-type: TEXT/PLAIN
>Content-transfer-encoding: 8BIT
>Precedence: bulk
>Managed-BY: RT 2.0.15 (http://bestpractical.com/rt/)
>RT-Ticket: openssl.org #366
>RT-Originator: [EMAIL PROTECTED]
>X-RT-Loop-Prevention: openssl.org
>X-Virus-Scanned: by AMaViS snapshot-20011031
>Original-recipient: rfc822;[EMAIL PROTECTED]
>
>
>The vms.mar I sent you had a small but important bug.  Please try this
>one instead.
>
>-- 
>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  for more info.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE[2]: [openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz

[[EMAIL PROTECTED] via RT]

>Download it from the RT ticket. RT2 kindly did not sent the 100k attachement
>to the whole list :-)

Oh great!  Now a whole list is going to know that this instruction is
meaningless to me :^)  Could you explain what is meant by "Download it
from the RT ticket."  Thanks.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE[3]: [openssl.org #366] OpenVMS openssl-0.9.7-beta4.tar.gz

[[EMAIL PROTECTED] via RT]

O'Oh, more embarressment.  I have just (accidentally) deleted your
reply.  Would you mind resending.  TIA.

>>Download it from the RT ticket. RT2 kindly did not sent the 100k attachement
>>to the whole list :-)
>
>Oh great!  Now a whole list is going to know that this instruction is
>meaningless to me :^)  Could you explain what is meant by "Download it
>from the RT ticket."  Thanks.
>

Regards,

++
 Mark Daniel http://wasd.vsm.com.au/adelaide
 mailto:[EMAIL PROTECTED] ([EMAIL PROTECTED])
++

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #201] OpenSSL 0.9.6e failing make test

[[EMAIL PROTECTED] via RT]

On December 2, 2002 05:53 am, Lutz Jaenicke via RT wrote:
> On Mon, Dec 02, 2002 at 10:55:26AM +0100, Alain Guibert via RT wrote:
> > There is just an alert at some point:
> > | installing man3/engine.3
> > | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 34
> > | of engine.pod: head3 ../../util/pod2man.pl: Unrecognized pod
> > | directive in paragraph 39 of engine.pod: head3
> > | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 59
> > | of engine.pod: head3 ../../util/pod2man.pl: Unrecognized pod
> > | directive in paragraph 62 of engine.pod: head3
> > | ../../util/pod2man.pl: Unrecognized pod directive in paragraph 69
> > | of engine.pod: head3 ../../util/pod2man.pl: Unrecognized pod
> > | directive in paragraph 73 of engine.pod: head3
> >
> > But the installation continues, and "man engine" is there after.
>
> Hmm. According to http://www.perldoc.com/perl5.6/pod/perlpod.html
> there only exist =head1 and =head2, so the complaint is correct :-)
>
> Geoff???

Hmm, bollocks. I can't confess to having studied the perlpod documentation 
on this - I merely wondered if I could get away with a third level of 
header nesting and it "just worked" on my installation (ie. I got no 
warnings/errors and the resulting man-page rendered fine). Is this a 
limitation in (some versions of) 'pod2man' or is it a safety measure 
because of limitations in (some versions of) 'man'? It seems a shame to 
have to ditch something that works if it's a limitation in the version of 
the conversion tool being used. Lutz, you are the doc-god, what do you 
think we should do? I'm obviously the first to want a third level of 
header nesting, but I may not be the last ...

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

The bastards have beaten off rationalism for now, but haven't eliminated 
our capacity for reason - to do that they'd have to make us forget how
to both think and fear at the same time.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign

[[EMAIL PROTECTED] via RT]

Ah, that is a good point in the case where we saw
this, the source bio was a bio_s_mem, i.e. a memory
bio, so it was not doing "r" text-mode eol
translation.  In other instances we do use the "r"
mode with file bios, and I guess that might explain
why we never saw it happen in those functions...
although it could also be that we never had a line of
text that was exactly 1022 characters long. :)

In any case, I don't believe that memory bios can be
set to text-mode... can they?

--Peter Lincroft


--- Richard Levitte via RT <[EMAIL PROTECTED]> wrote:
> 
> A couple of questions:
> 
> - which type of source BIO did you use when this
> happened?
> - if it was a text file, was it opened in binary
> mode?
> 
> In case it was a text file opened in binary mode, do
> you get a 
> better behavior if it's opened in text mode?  You
> see, in text 
> mode, CRLF is supposed to be converted to LF, and
> hopefully 
> *before* the length of the buffer is checked...
> 
> [[EMAIL PROTECTED] - Fri Nov 22 10:27:16 2002]:
> 
> > 
> > OS: Windows, but I think it is a cross-platform
> bug.
> > Version: 0.9.6g
> > 
> > In the following function which is called from
> > PKCS7_sign, if the source text contains a line of
> text
> > which is exactly a mutiple of MAX_SMLEN-2
> characters
> > long and has a CRLF line ending, then the gets
> call
> > will return a buffer which ends with just a CR,
> and
> > then on the next call a line that contains just an
> LF,
> > which will result in two CRLF pairs being put into
> the
> > output.
> 
> -- 
> Richard Levitte
> 
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #356] Bug in CRLF translation in PKCS7_sign

[[EMAIL PROTECTED] via RT]

> 
> No they can't.  However, if CRLF are showing up in
> them, it means you
> have put it in there some way, perhaps from
> transfering a file in
> binary mode to it?
> 
> Text mode vs. binary mode is tricky business...
> 

Hm.  I guess what you are saying is that the function
in question assumes that any non-binary input has its
line-endings normalized to be LF only.  It then
converts all the LF-only line endings to CRLF.  I
think in our case we actually have some code that
explicitly normalizes the line endings to CRLF
_before_ passing it in.  We "fixed" the problem in our
case by changing our call to specify the "BINARY"
flag, since we knew our line-endings were already
normalized to CRLF.  I guess the really confusing part
of this is that the PKCS7 functions for verification
seem to assume normalized CRLF line-endings in some
places, but the signature creation functions seem to
assume LF-only line-endings (at least that is what you
seem to be saying).

Anyway, I guess this is not a bug, if you assert that
the input should be normalized to LF-only
line-endings.  I thought that the purpose of this bit
of code was to normalize _either_ LF-only OR CRLF
line-ending to CRLF, which it clearly does not do. 
BTW, if it is given CRLF, it does NOT convert them to
CRCRLF in most cases, it leaves them as CRLF.  Perhaps
that was the source of my confusion... it handles CRLF
line-endings "correctly" most of the time... but not
if they fall on certain buffer-size boundaries.

--Peter Lincroft



__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6

[[EMAIL PROTECTED] via RT]

Using the lynx browser compiled with openssl, the environment
variable SSL_CERT_FLLE seems to be ignored. If I place the trusted
root certificates in the default location, the application finds
them without difficulty. If placed in a non-default location,
setting the value of SSL_CERT_FILE to that location doesn't allow
the certificates to be read in. I recently noted this with the
20021115 snapshot of openssl 0.9.7. I now see that a similar
report was noted earlier on the lynx-dev mailing list with a
proposed patch for openssl 0.9.6g by Takeshi Hataguchi (see:
"http://www.flora.org/lynx-dev/html/month102002/msg00057.html";).
Applying that patch to 0.9.7 led to a failure in "make test", so
it may not be the appropriate patch. I don't remember seeing this
discussion on openssl-dev.

Could someone verify independently that SSL_CERT_FILE doesn't allow
reading certificates in non-default locations? If verified, can
someone familiar with how this is supposed to work come up with a
patch? The code for this is in crypto/x509/by_file.c, with similar
code for SSL_CERT_DIR in crypto/x509/by_dir.c (with associated code
in crypto/x509/x509_def.c and crypto/cryptlib.h). If this is really a
problem with the application, let me know and I will take the problem
back to the lynx-dev mailing list.

Thanks.
Doug

__
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6

[[EMAIL PROTECTED] via RT]

On Tue, 3 Dec 2002, Doug Kaufman wrote:

> Using the lynx browser compiled with openssl, the environment
> variable SSL_CERT_FLLE seems to be ignored. If I place the trusted
> root certificates in the default location, the application finds
> them without difficulty. If placed in a non-default location,
> setting the value of SSL_CERT_FILE to that location doesn't allow
> the certificates to be read in. I recently noted this with the

Replying to my own post. I see that there was a similar discussion
more than a year ago on openssl-dev. Please see the post by Steve
Henson. Is this the same problem that never got fixed?
"http://www.mail-archive.com/openssl-dev@openssl.org/msg09920.html";
   Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #376] Possible SSL_CERT_FILE bug in 0.9.7 and 0.9.6

[[EMAIL PROTECTED] via RT]

On Wed, 4 Dec 2002, Richard Levitte - VMS Whacker via RT wrote:

> In message <[EMAIL PROTECTED]> on Wed,  4 Dec 2002 09:24:39 
>+0100 (MET), "[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]> said:
>
> rt> Could someone verify independently that SSL_CERT_FILE doesn't
> rt> allow reading certificates in non-default locations?
>
> I can verify, by looking at the code, that SSL_CERT_FILE should work,
> but only if the default cert file (/usr/local/ssl/cer.pem?) doesn't
> exist or is faulty.  Basically, the system default seems to have
> precedence...

Yes, it _should_ work, but it doesn't. I have tested with no file in
the system default location, and the file pointed to by SSL_CERT_FILE
still doesn't get read. A non-existent file shouldn't take precedence
over an existing file. Even in the case of an existing default file,
what would be the purpose of SSL_CERT_FILE if it can't change the
default?
  Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #201] OpenSSL 0.9.6e failing make test

[[EMAIL PROTECTED] via RT]

On December 3, 2002 03:09 am, Lutz Jaenicke via RT wrote:
> On Mon, Dec 02, 2002 at 08:35:43PM +0100, [EMAIL PROTECTED] via RT 
wrote:
> > > Hmm. According to http://www.perldoc.com/perl5.6/pod/perlpod.html
> > > there only exist =head1 and =head2, so the complaint is correct :-)
> > >
> > > Geoff???
> >
> > Hmm, bollocks. I can't confess to having studied the perlpod
> > documentation on this - I merely wondered if I could get away with a
[snip]
> > you are the doc-god, what do you think we should do? I'm obviously
> > the first to want a third level of header nesting, but I may not be
> > the last ...
>
> With respect to the link I cited above, the =head directive only
> supports level 1 and level 2. If we intend to maintain compatibility
> with standard perlpod, and I think we do :-), there is no level 3 and
> that is it. Thus the manual page needs restructuring.

Well I decided to do a little fishing ... this is apparently not a 
limitation of groff/man (which is what counts, after all) but a 
limitation of the pod2man implementation in version 5.6 of perl. Version 
5.8 gives *four* levels of nesting;

http://www.perldoc.com/perl5.8.0/pod/perlpod.html

I can go and cripple the engine.pod documentation if absolutely necessary, 
but it simply seems a somewhat shortsighted solution (even if 
alliterative :-). IIRC there was some discussion a while back about 
bundled implementations of pod2man or something like that? Could we 
simply use a 5.8-compatible bundled implementation if the host system's 
version is too old?

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

The bastards have beaten off rationalism for now, but haven't eliminated 
our capacity for reason - to do that they'd have to make us forget how
to both think and fear at the same time.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #385] 0.9.7-stable build fails on OpenBSD 2.9

[[EMAIL PROTECTED] via RT]

On Thu, Dec 05, 2002 at 10:26:58AM +0100, Richard Levitte - VMS Whacker wrote:
> In message <[EMAIL PROTECTED]> on Thu,  5 Dec 2002 10:03:20 
>+0100 (MET), " via RT" <[EMAIL PROTECTED]> said:
> 
> rt> gcc -I.. -I../.. -I../../include -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H
> rt> -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
> rt> -DSHA1_ASM -DMD5_ASM -DRMD160_ASM  -c hw_cryptodev.c
> rt> hw_cryptodev.c:49: crypto/cryptodev.h: No such file or directory
> rt> 
> rt> (I think that header is only available in OpenBSD 3.0 and later)
> 
> Is there any way to detect this with built-in C macros?

Ah, I've found this in :

#define OpenBSD 200105  /* OpenBSD version (year & month). */
#define OpenBSD2_9 1/* OpenBSD 2.9 */

so if we can work out what year&month is used in the first release with
this crypto/cryptodev.h header this can probably be used.

joe

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #386] DJGPP patch for 0.9.7

[[EMAIL PROTECTED] via RT]

The recent patch for DJGPP paths didn't work. I think that this is
what was intended. I will be away and not able to do any testing for
about a week. "make install_docs" is failing for multiple man pages,
but I haven't been able to debug it before I have to leave.

The patch is against the 200021204 snapshot of 0.9.7.
Doug

__
Doug Kaufman
Internet: [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #391] compilation failure

[[EMAIL PROTECTED] via RT]

OpenSSL self-test report:

OpenSSL version:  0.9.7-beta6-dev
Last change:  In asn1_d2i_read_bio() repeatedly call BIO_read() until...
Options:   no-krb5
OS (uname):   OSF1 pierredelune.i3s.unice.fr V5.0 910 alpha alpha
OS (config):  alpha-dec-tru64
Target (default): alpha-cc
Target:   alpha-cc
Compiler: Compaq C V6.1-011 on Digital UNIX V5.0 (Rev. 910)

Failure!
-
make[1]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207'
making all in crypto...
make[2]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto'
making all in crypto/md2...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/md2'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/md2'
making all in crypto/md4...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/md4'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/md4'
making all in crypto/md5...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/md5'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/md5'
making all in crypto/sha...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/sha'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/sha'
making all in crypto/mdc2...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/mdc2'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/mdc2'
making all in crypto/hmac...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/hmac'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/hmac'
making all in crypto/ripemd...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/ripemd'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/ripemd'
making all in crypto/des...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/des'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/des'
making all in crypto/rc2...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/rc2'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/rc2'
making all in crypto/rc4...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/rc4'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/rc4'
making all in crypto/rc5...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/rc5'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/rc5'
making all in crypto/idea...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/idea'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/idea'
making all in crypto/bf...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/bf'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/bf'
making all in crypto/cast...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/cast'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/cast'
making all in crypto/bn...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/bn'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/bn'
making all in crypto/ec...
make[3]: Entering directory 
`/usr/users/localsrc/Divers/openssl-0.9.7-stable-SNAP-20021207/crypto/ec'
make[3]: Nothing to be done for `all'.
make[3]:

Re: [openssl.org #398] AutoReply: DJGPP patch for openssl-0.9.7 (install_docs)

[[EMAIL PROTECTED] via RT]

On Fri, 13 Dec 2002, Richard Levitte - VMS Whacker wrote:

> I believe that it's quite dangerous to assume -i on Unixly systems,
> entirely depending on the order in which the names come up.  Also, the
> thing to grep for is the full name, so instead of \>, one can use \$.
> Finally, on Unixly systems, I really want the softlinks to just have
> the file name as value, not the full path.
> 
> I made the attached change, please test it and see if that satisfies
> your needs.  And also, if you have the inclination, a test on Cygwin
> would be a good thing (does Cygwin have entirely case-sensitive file
> names or not?).

Yes, this patch fixes the problem for installation of man pages on
DJGPP. I also tested with and without the patch on Cygwin, using the
latest CVS version of 0.9.7-stable. Cygwin also had the problem of the
manpage getting clobbered by an attempt to link to a file with a name
differing only in case. The patch fixes this for Cygwin also. Please
commit the patch if you don't see any other problems with it.

Cygwin fails compilation because of a problem with the asm modules in
crypto/des. Since that seems to be a separate problem, I'll send that
to rt to generate a new ticket.

Cygwin file names are case aware, but I am not sure that you can call
them case sensitive. Cygwin (and Windows) can remember that a file
is named "FILE.txt" rather than "file.txt", but "rm file.txt" will
remove "FILE.txt", and the filesystem sees the names as referring to
the same file. Individual programs can have case-sensitive arguments,
however. For instance, the man program on both Cygwin and DJGPP is
case sensitive for arguments. "man ASN1_OBJECT_new" will get the man
page, but "man asn1_object_new" will return an error that the man page
does not exist.
  Doug

__ 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #401] Bug in openssl-0.9.7-stable install_docs (head3)

[[EMAIL PROTECTED] via RT]

I know that the problem of "head3" in the pod files has been brought up
before, but I thought it had been resolved. Doing "make install_docs",
using the latest 0.9.7-stable files from cvs, I get an error in
processing doc/crypto/engine.pod, related to "head3". The man page is
created, but is truncated at the first "head3" in the pod file. This is
the only file where I see the problem. The error message that I get is:

installing man3/engine.3
Can't locate object method "cmd_head3" via package "Pod::Man" at \
/usr/local/lib/perl5/5.6.0/Pod/Man.pm line 463,  line 191.

The engine.pod file is dated 4 August 2002.
Doug

-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #403] open ssl error . urgent help needed

[[EMAIL PROTECTED] via RT]

Did you discover any fix, yet ?
I am working on a similar issue.
Initially I had to verify the PATH variable - so that it could find the
Compiler as well the make utility.
which I confirmed by running [ cc -v ] or [ gcc  - v ] and [make]

Good Luck

Ashik


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #435] ssl proxy, core dump in certificate validation when acting as a client

[[EMAIL PROTECTED] via RT]

Hi Lutz,

Sorry to email you directly, but I was unable to send any message to the
openssl-users mailing list.  I tried sending the message via Google too and
it also didn't work.  I think my subscription is still valid.


We are facing   CORE DUMP in ssl library during cerificate chain validation
in the following
Scenario:

 working for ssl proxy ( single ssl context is used ). it is working fine (
ie accepting ssl connections and establishing ssl connections ) with
self signed certificates. But we are failing to establish ssl connection
with certificate chains.

we succeeded in accepting ssl connections, but when we try to establish a
secure connection ( ie when we try SSL_connect)
it core dumps at  X509_NAME_cmp () in the library.

---Type  to continue, or q  to quit---
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
#0  0x001eb56c in X509_NAME_cmp () at src/sipexception.cpp:102
102 return "Invalid code";
(gdb) where
#0  0x001eb56c in X509_NAME_cmp ()
#1  0x001fb404 in X509_check_issued ()
#2  0x001ec730 in check_issued ()
#3  0x001ec048 in X509_verify_cert ()
#4  0x001acf94 in ssl_verify_cert_chain ()
#5  0x001baa98 in ssl3_get_server_certificate ()
#6  0x001b9b90 in ssl3_connect ()

#7  0x000740b0 in sslConnect (this=0x3b1768)

#8  0x00072d40 in tlsSelectThread (this=0x3b1768)


(gdb)

Any pointers for the solution to the above problem.

Rgards
Channa








This message is proprietary to Hughes Software Systems Limited (HSS) and is
intended solely for the use of the individual to whom it is addressed.  It
may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.  If
you have received this message in error, please notify the originator
immediately.  If you are not the intended recipient, you are notified that
you are strictly prohibited from using, copying, altering, or disclosing
the contents of this message.  HSS accepts no responsibility for loss or
damage arising from the use of the information transmitted by this email
including damage from virus.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #436] openssl-0.9.7 inconsistency error

[[EMAIL PROTECTED] via RT]

Yes, sorry about that.  I am running the most recent version of
Slackware Linux. I am running Apache webserver and looking to run secure
webpages from the server.  I have the folder with the openssl and I can
run config fine, had to add full permissions to the folder, but when I
run Make I get that error.  I enclosed a screen shot of what I get.  I
do appreciate your help, thanks much.
Joe



-Original Message-
From: Lutz Jaenicke via RT [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, January 04, 2003 6:28 AM
To: Joseph A. Amaturo
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #436] openssl-0.9.7 inconsistency error



On Sat, Jan 04, 2003 at 01:09:07AM +0100,  via RT wrote:
> 
> after completing ./config and make i get :
> 
> cryptlib.c:109: #error "Inconsistency between crypto.h and cryptlib.c"
> make[1]: *** [cryptlib.o] Error 1

Do you have any more information, like operating system etc.?

Best regards,
Lutz
-- 
Lutz Jaenicke
[EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

Thanks.   I was going to recreate the list locally.

I have a read-only path to the source and was going to run through a
Configure/build test to make sure that nothing is broken.

I'll make sure that any relative links (the include files and a few
others) stay relative in the build area, and anything else that is
modified by Configure/build is also local to the build area.

Prior to this i've just built in the source, installed (into a packaging
directory), cleaned, made again for the sparcv9 version, installed (into
a different packaging directory) and then made a combined package that
understands at (package installation time) whether it should include
sparcv9 specific versions on the target host.

I thought i'd keep things a little cleaner by building outside the
source this time round, but it's been more hassle than I expected.I
am surprised that no one else has griped that it doesn't work as least
as well as many other packages that build for multiple architectures.


\nick


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #436] openssl-0.9.7 inconsistency error

[[EMAIL PROTECTED] via RT]

Is there something I can do, use a different file?  Any help?  Thanks
much.

Joseph A Amaturo
President
Amatech Solutions, Inc.
AT Concepts, Inc.
(P) 845-988-9876
(C) 845-590-7914
(F) 845-988-9899
www.amatechsolutions.com
Microsoft Certified Partner


-Original Message-
From: Lutz Jaenicke via RT [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, January 08, 2003 3:53 AM
To: Joseph A. Amaturo
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #436] openssl-0.9.7 inconsistency error 



[[EMAIL PROTECTED] - Sat Jan  4 15:13:09 2003]:

> Yes, sorry about that.  I am running the most recent version of 
> Slackware Linux. I am running Apache webserver and looking to run 
> secure webpages from the server.  I have the folder with the openssl 
> and I can run config fine, had to add full permissions to the folder, 
> but when I run Make I get that error.  I enclosed a screen shot of 
> what I get.  I do appreciate your help, thanks much.

Hmm. I don't now what should be causing the problem. It seems that
somehow a wrong header file is being used.

Best regards,
Lutz

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

I think a sufficient requirement is that files in the source tree that
are relative links need to be recreated as relative links within the
platform dependent directory.   If you just leave out the "-o -type l"
you won't make any of the links, and the include/openssl directory will
be empty, which will fail.   Of course your source directory needs to be
absent any residual configuration -- which would cause the script to
make links to files that would be created by Configure and might then
cause subsequent Configures to update the source tree version.

Overall, I think I prefer (modern) make's VPATH, but i'm not sure that
that fits your requirements for portability.

\nick


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

I'll try the next snapshot.Thanks.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #453] Re: DJGPP patch for 0.9.7-stable

[[EMAIL PROTECTED] via RT]

On Sun, 12 Jan 2003, Andy Polyakov wrote:

> > dkaufman> I noticed that the makefile contains a special line for
> > dkaufman> DJGPP, similar to the one for Cygwin. This isn't needed for
> > dkaufman> DJGPP. Patch attached.
> > 
> > Please explain why .dll loading would be different in that particular
> > case...
> 
> Because loading of Windows .dll is not an option in DJGPP? Isn't DJGPP
> so to say all own OS? At least it doesn't rely upon WIN32 API, but
> MS-DOS "int 21h" and *if* it supports some kind of dynamicaly loadable
> objects, it has nothing to do with Windows LoadLibrary call, the one
> using %PATH% to look for .dlls. A.

To clarify, DJGPP runs in a true DOS environment rather than a Windows
environment. Multitasking is not supported. It does not support
dynamically loaded libraries at all. DJGPP binaries can run in a DOS
box under Windows, but run as DOS rather than native Windows programs.
  Doug
-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #433] 0.9.7 compilation problem with Borland C++ 5.5

[[EMAIL PROTECTED] via RT]

> > [[EMAIL PROTECTED] - Fri Jan  3 06:45:12 2003]: 
> >  
> > > I'm trying to compile 0.9.7 with Borland C++ 5.5 and NASM 0.98.35 on 
> > > Windows XP Professional SP1 with all updates. 
> > >  
> > > .\crypto\x509\x_all.c: 
> > > Error E2450 .\crypto\x509\x_all.c 72: Undefined structure 
> > 'ASN1_ITEM_st' 

This same error happpened for me when compiling with Builder 5.  I
haven't checked Builder 6 yet.  This is the one outstanding error for
Builder 5 for which I still have local patches - I did submit a working
fix for this some time ago, but it was kind-of controversial and didn't
make it in.

-- 
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com/


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #472] Exception when running "openssl req" command after Jan 18th

[[EMAIL PROTECTED] via RT]

I have tried this with both 0.9.7-beta 3 and the official 0.9.7 release.

Under windows, running the "openssl req" command causes an exception in
libeay32.dll.  I found this on a machine that had been working perfectly and
then suddenly started exceptioning.  On the advice of a co-developer, I
tried setting the date back on my PC.

Lo and behold, I find that it works when I have my PC set to Jan 18th, 2003
or earlier, but the second I am on Jan 19th or later I get the exception.


Please let me know if there is any other useful information I can obtain.  I
have not had a chance to try this on a Linux system yet, only Windows.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #474] [PATCH]

[[EMAIL PROTECTED] via RT]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #472] Exception when running "openssl req" comma nd after Jan 18th

[[EMAIL PROTECTED] via RT]

Stephen,

Thanks for the reply.  We were kind of hit over the head with this, as it
had been working fine for quite a while with no problems and suddenly blew
up on us.

Both the openssl application and the 2 dll's are the official 0.9.7 release.
I searched the machine and these are the only versions on the machine.  I
have tried this on several machines also, just to eliminate any concern that
it is my machine.  I also tried a few of the recent snapshot stable builds
and they exhibit the same problem.  I have not backed up and tried a 0.9.6
build yet.

The exact command that I ran was:
"openssl req -config openssl.cnf -new -x509 -days 12784 -sha1
 -newkey rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem
-passin
file:CA\pass\ca_pp -passout file:CA\pass\caout_pp"

Where ca_pp and caout_pp are both simple text files with a single line
containing a passphrase.


Here is the output from my DOS windows:

C:\uap8245\tools\ca>openssl req -config openssl.cnf -new -x509 -days 12784
-sha1
 -newkey rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem
-passin
file:CA\pass\ca_pp -passout file:CA\pass\caout_pp
Using configuration from openssl.cnf
Loading 'screen' into random state - done
Generating a 1024 bit RSA private key
...++
...++
writing new private key to 'CA\private\cakey.pem'
-
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-
Country Name (2 letter code) [US]:
State or Province Name (full name) [Washington]:
Locality Name (eg, city) [Everett]:
Organization Name (eg, company) [Intermec Technologies Corporation]:
Organizational Unit Name (eg, section) [Security Engineering]:
Common Name (eg, YOUR name) [Intermec Technologies Corporation]:
Email Address []:

Immediately after receiving all of the input information for the cert, I get
the exception.  It looks from the nice cryptic windows message that somebody
is accessing a null pointer, the windows error message is:

"openssl.exe - Application Error
The instruction at "0x0035bccc" referenced memory at "0x".  The
memory could not be "read".


Opening a debugger provides the following error message:
"Unhandled exception in openssl.exe (LIBEAY32.DLL): 0xC005: Access
Violation"


To give more information than you probably want, here are the registers:

EAX =  EBX = 
 ECX =  EDX = 003D0608
 ESI = 00933708 EDI = 00933E80
 EIP = 0035BCCC ESP = 0012F46C
 EBP = 009310F8 EFL = 0246
 MM0 = 
 MM1 = 
 MM2 = 
 MM3 = 
 MM4 = 
 MM5 = 
 MM6 = 
 MM7 = B400
 XMM0 = 
 XMM1 = 
 XMM2 = 
 XMM3 = 
 XMM4 = 
 XMM5 = 
 XMM6 = 
 XMM7 = 
 CS = 001B DS = 0023 ES = 0023 SS = 0023
 FS = 0038 GS =  OV=0 UP=0 EI=1 PL=0
 ZR=1 AC=0 PE=1 CY=0
 XMM0DL = +0.00E+000
 XMM0DH = +0.00E+000
 XMM1DL = +0.00E+000
 XMM1DH = +0.00E+000
 XMM2DL = +0.00E+000
 XMM2DH = +0.00E+000
 XMM3DL = +0.00E+000
 XMM3DH = +0.00E+000
 XMM4DL = +0.00E+000
 XMM4DH = +0.00E+000
 XMM5DL = +0.00E+000
 XMM5DH = +0.00E+000
 XMM6DL = +0.00E+000
 XMM6DH = +0.00E+000
 XMM7DL = +0.00E+000
 XMM7DH = +0.00E+000
 XMM00 = +0.0E+000
 XMM01 = +0.0E+000
 XMM02 = +0.0E+000
 XMM03 = +0.0E+000
 XMM10 = +0.0E+000
 XMM11 = +0.0E+000
 XMM12 = +0.0E+000
 XMM13 = +0.0E+000
 XMM20 = +0.0E+000
 XMM21 = +0.0E+000
 XMM22 = +0.0E+000
 XMM23 = +0.0E+000
 XMM30 = +0.0E+000
 XMM31 = +0.0E+000
 XMM32 = +0.0E+000
 XMM33 = +0.0E+000
 XMM40 = +0.0E+000
 XMM41 = +0.0E+000
 XMM42 = +0.0E+000
 XMM43 = +0.0E+000
 XMM50 = +0.0E+000
 XMM51 = +0.0E+000
 XMM52 = +0.0E+000
 XMM53 = +0.0E+000
 XMM60 = +0.0E+000
 XMM61 = +0.0E+000
 XMM62 = +0.0E+000
 XMM63 = +0.0E+000
 XMM70 = +0.0E+000
 XMM71 = +0.0E+000
 XMM72 = +0.0E+000
 XMM73 = +0.0E+000 MXCSR = 1F80
 ST0 = +0.0e+
 ST1 = +0.0e+
 ST2 = +0.0e+
 ST3 = +0.0e+
 ST4 = +0.0e+
 ST5 = +0.0e+
 ST6 = +0.0e+
 ST7 = +4.5e+0001
 CTRL = 027F STAT =  TAGS = 
 EIP = 00350C69
 CS = 001B DS = 0023 

RE: [openssl.org #472] Exception when running "openssl req" comma nd after Jan 18th

[[EMAIL PROTECTED] via RT]

Sorry, SP5 not SP6.

I figured it had to do with a time value overflowing a variable size.  I'll
crank down the days value temporarily to workaround it.

Thanks for the help.  Felt silly sending off the report instead of just
digging in and fixing it, but staying ahead of layoffs here has kept me more
than busy.

-Jason

-Original Message-
From: Stephen Henson via RT [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 23, 2003 12:46 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #472] Exception when running "openssl req" command
after Jan 18th 



[[EMAIL PROTECTED] - Thu Jan 23 15:33:56 2003]:

> Stephen,
> 
> Thanks for the reply.  We were kind of hit over the head with this, as 
> it had been working fine for quite a while with no problems and 
> suddenly blew
> up on us.
> 
> Both the openssl application and the 2 dll's are the official 0.9.7 
> release. I searched the machine and these are the only versions on the 
> machine. I
> have tried this on several machines also, just to eliminate any
> concern that
> it is my machine.  I also tried a few of the recent snapshot stable
> builds
> and they exhibit the same problem.  I have not backed up and tried a
> 0.9.6
> build yet.
> 
> The exact command that I ran was:
> "openssl req -config openssl.cnf -new -x509 -days 12784 -sha1  -newkey 
> rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem
> -passin
> file:CA\pass\ca_pp -passout file:CA\pass\caout_pp"
> 
[stuff deleted]
> 
> Regarding compiler, I used Visual C++ 6.0 with service pack 6.  nmake 
> version 6.00.8168.0.
> 

Whats SP6? Never seen that, I've got SP5 though...

> I am running Windows XP, SP1 with all the updates.
> 
> 

The cause is that rather large value you use for -days and the behaviour of
the Windows gmtime function.

If the value of time_t passed to gmtime under Windows is a date before the
1970 epoch it returns NULL instead of the static pointer to the tm
structure. This isn't handled properly by the openssl code and causes a
crash.

The reason the time appears before the epoch is that time_t is a signed long
on Win32 and if you add a big enough value it wraps around and ends up
negative. So if you give a large enough -days value this will happen.

The workaround is to use a smaller -days value.

We should fix the openssl utility to check for errors in the appropriate
functions, which would at least stop the crash and give some meaningful
error message.

Ideally I suppose we should have alternative routines which can handle
larger dates.

Steve.







__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #436] openssl-0.9.7 inconsistency error

[[EMAIL PROTECTED] via RT]

I can't get it.  So lets drop and and try again later

Joseph A Amaturo
President
Amatech Solutions, Inc.
AT Concepts, Inc.
(P) 845-988-9876
(C) 845-590-7914
(F) 845-988-9899
www.amatechsolutions.com
Microsoft Certified Partner


-Original Message-
From: Lutz Jaenicke via RT [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 23, 2003 2:27 AM
To: Joseph A. Amaturo
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #436] openssl-0.9.7 inconsistency error 



[jaenicke - Wed Jan 15 12:30:08 2003]:

> Any new information?

No response for another week.

I therefore close the ticket.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #475] [Fwd: patch to 0.9.7 -performacne]

[[EMAIL PROTECTED] via RT]

On Sun, 26 Jan 2003, David Brumley via RT wrote:

> I'm in the US, but just a simple researcher :)  I don't pretend to know
> anything about our crazy laws on crypto.

The rules do seem silly, but the US deems it "exporting" when you post
crypto-related material on the internet. For freely available source
code, all you have to do is send notification of the URL where the code
is (or copies of the code), to two internet addresses. One is at the
Department of Commerce. I am not sure where the other is, but it is
probably the National Security Agency's National Cryptologic School in
Fort Meade. The instructions are at:
'Notification Requirements for "Publicly Available" Encryption Source Code'
URL: "http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html";

Note that the URL is really "Nofify" not Notify.
Doug
-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

I've checked over the snapshot that was current on or about 14-Jan-2003.
It builds OK.

In the original 0.9.7.tar.gz there were symbolic links already present
in include/openssl, and they are not removed by make clean.   In the
snapshot the links are not present.

Script started on Mon Jan 27 10:15:14 2003
kea> gzcat openssl-0.9.7-stable-SNAP-20030114.tar.gz | tar tf - | grep
include
openssl-0.9.7-stable-SNAP-20030114/VMS/test-includes.com
openssl-0.9.7-stable-SNAP-20030114/include/

kea> gzcat openssl-0.9.7.tar.gz  | tar tf - | grep include
openssl-0.9.7/include/
openssl-0.9.7/include/openssl/
openssl-0.9.7/include/openssl/aes.h symbolic link to
../../crypto/aes/aes.h
openssl-0.9.7/include/openssl/asn1.h symbolic link to
../../crypto/asn1/asn1.h
openssl-0.9.7/include/openssl/asn1_mac.h symbolic link to
../../crypto/asn1/asn1_mac.h
openssl-0.9.7/include/openssl/asn1t.h symbolic link to
../../crypto/asn1/asn1t.h
openssl-0.9.7/include/openssl/bio.h symbolic link to
../../crypto/bio/bio.h
openssl-0.9.7/include/openssl/blowfish.h symbolic link to
../../crypto/bf/blowfish.h
openssl-0.9.7/include/openssl/bn.h symbolic link to ../../crypto/bn/bn.h
openssl-0.9.7/include/openssl/buffer.h symbolic link to
../../crypto/buffer/buffer.h
openssl-0.9.7/include/openssl/cast.h symbolic link to
../../crypto/cast/cast.h
openssl-0.9.7/include/openssl/comp.h symbolic link to
../../crypto/comp/comp.h
openssl-0.9.7/include/openssl/conf_api.h symbolic link to
../../crypto/conf/conf_api.h
openssl-0.9.7/include/openssl/conf.h symbolic link to
../../crypto/conf/conf.h
openssl-0.9.7/include/openssl/crypto.h symbolic link to
../../crypto/crypto.h
openssl-0.9.7/include/openssl/des.h symbolic link to
../../crypto/des/des.h
openssl-0.9.7/include/openssl/des_old.h symbolic link to
../../crypto/des/des_old.h
openssl-0.9.7/include/openssl/dh.h symbolic link to ../../crypto/dh/dh.h
openssl-0.9.7/include/openssl/dsa.h symbolic link to
../../crypto/dsa/dsa.h
openssl-0.9.7/include/openssl/dso.h symbolic link to
../../crypto/dso/dso.h
openssl-0.9.7/include/openssl/ebcdic.h symbolic link to
../../crypto/ebcdic.h
openssl-0.9.7/include/openssl/ec.h symbolic link to ../../crypto/ec/ec.h
openssl-0.9.7/include/openssl/engine.h symbolic link to
../../crypto/engine/engine.h
openssl-0.9.7/include/openssl/e_os2.h symbolic link to ../../e_os2.h
openssl-0.9.7/include/openssl/err.h symbolic link to
../../crypto/err/err.h
openssl-0.9.7/include/openssl/evp.h symbolic link to
../../crypto/evp/evp.h
openssl-0.9.7/include/openssl/hmac.h symbolic link to
../../crypto/hmac/hmac.h
openssl-0.9.7/include/openssl/idea.h symbolic link to
../../crypto/idea/idea.h
openssl-0.9.7/include/openssl/krb5_asn.h symbolic link to
../../crypto/krb5/krb5_asn.h
openssl-0.9.7/include/openssl/kssl.h symbolic link to ../../ssl/kssl.h
openssl-0.9.7/include/openssl/lhash.h symbolic link to
../../crypto/lhash/lhash.h
openssl-0.9.7/include/openssl/md2.h symbolic link to
../../crypto/md2/md2.h
openssl-0.9.7/include/openssl/md4.h symbolic link to
../../crypto/md4/md4.h
openssl-0.9.7/include/openssl/md5.h symbolic link to
../../crypto/md5/md5.h
openssl-0.9.7/include/openssl/mdc2.h symbolic link to
../../crypto/mdc2/mdc2.h
openssl-0.9.7/include/openssl/objects.h symbolic link to
../../crypto/objects/objects.h
openssl-0.9.7/include/openssl/obj_mac.h symbolic link to
../../crypto/objects/obj_mac.h
openssl-0.9.7/include/openssl/ocsp.h symbolic link to
../../crypto/ocsp/ocsp.h
openssl-0.9.7/include/openssl/opensslconf.h symbolic link to
../../crypto/opensslconf.h
openssl-0.9.7/include/openssl/opensslv.h symbolic link to
../../crypto/opensslv.h
openssl-0.9.7/include/openssl/ossl_typ.h symbolic link to
../../crypto/ossl_typ.h
openssl-0.9.7/include/openssl/pem2.h symbolic link to
../../crypto/pem/pem2.h
openssl-0.9.7/include/openssl/pem.h symbolic link to
../../crypto/pem/pem.h
openssl-0.9.7/include/openssl/pkcs12.h symbolic link to
../../crypto/pkcs12/pkcs12.h
openssl-0.9.7/include/openssl/pkcs7.h symbolic link to
../../crypto/pkcs7/pkcs7.h
openssl-0.9.7/include/openssl/rand.h symbolic link to
../../crypto/rand/rand.h
openssl-0.9.7/include/openssl/rc2.h symbolic link to
../../crypto/rc2/rc2.h
openssl-0.9.7/include/openssl/rc4.h symbolic link to
../../crypto/rc4/rc4.h
openssl-0.9.7/include/openssl/rc5.h symbolic link to
../../crypto/rc5/rc5.h
openssl-0.9.7/include/openssl/ripemd.h symbolic link to
../../crypto/ripemd/ripemd.h
openssl-0.9.7/include/openssl/rsa.h symbolic link to
../../crypto/rsa/rsa.h
openssl-0.9.7/include/openssl/safestack.h symbolic link to
../../crypto/stack/safestack.h
openssl-0.9.7/include/openssl/sha.h symbolic link to
../../crypto/sha/sha.h
openssl-0.9.7/include/openssl/ssl23.h symbolic link to ../../ssl/ssl23.h
openssl-0.9.7/include/openssl/ssl2.h symbolic link to ../../ssl/ssl2.h
openssl-0.9.7/include/openssl/ssl3.h symbolic link to ../../ssl/ssl3.h
openssl-0.9.7/include/openssl/ssl.h symbolic link to ../../ssl/ssl.h
openssl-0.9.7/include/openssl/stack.h symbolic link to
../.

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

In the original 0.9.7 release there also seems to be some configuration
remnants left in the crypto/objects directory -- obj_dat.h;   this isn't
removed by a "make clean".

\nick 


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #479] support version independent upgrade

[[EMAIL PROTECTED] via RT]

Actually, I'd prefer that I wouldn't have to relink and redistribute my application 
every
time a security patch comes out for OpenSSL.  I haven't seen any issues in our 
application
upgrading from 0.9.6 to 0.9.7 using this non version technique on our local 
development nodes.

The version technique doesn't just prevent backward compatibility but it 
prevents users from getting potential security upgrades that *may* work
just fine.  It's definitely not a desirable distribution scenario as it sits now. 
It forces developers to do relinks and redistribute whether they're needed or not.

-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 2:10 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Jim Sahaj
Subject: Re: [openssl.org #479] support version independent upgrade 


In message <[EMAIL PROTECTED]> on Mon, 27 Jan 2003 22:40:24 
+0100 (MET), " via RT" <[EMAIL PROTECTED]> said:

rt> Currently, on many Unix platforms I link my application against 
rt> libssl.so and libcrypto.so. Typically, these are links set to resolve 
rt> down to the versioned types of these files, like libssl.so.0.9.7 and 
rt> libcrypto.so.0.9.7.  The internal names of these shared objects 
rt> include the major and minor version so even though I link against the 
rt> shared objects without the version, such as libssl.so, my application 
rt> becomes tied to the versioned shared objects at link time, for 
rt> instance libssl.so.0.9.7.

There's a reason: until OpenSSL 1, we don't guarantee backward binary
compatibility.  There are technical reasons for this, like the need to
make changes to published structures (it may be argued that it
shouldn't be needed, but to achieve such flexibility, we either need
to hide them (which would require huge changes for everyone) or redo
them in such a way that they become rather generic) and other stuff.

Because of this, we're forced to do what we currently do with shared
libraries.  Perhaps you'd prefer that your applications crash
mysteriously and in an unrecoverable manner?

-- 
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  for more info.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...

[[EMAIL PROTECTED] via RT]

Hi there !

I thought this was worth mentioning:

Very reproducably, openssl ca crashes each time when having finished the job.
(Worked in 0.9.6x)

Here's some info for the bug report:


System(s):
Win98SE/WinNT4.0Sp6 on INTEL(PIII, 666Mhz and others), MSVC++6Sp5, Version 12.00.8804

OpenSSL:
OpenSSL 0.9.7 31 Dec 2002
built on: Thu Jan 23 09:11:54 2003
platform: VC-WIN32
options:  bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) idea(int) blowfish(idx)
compiler: cl  /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo 
-DOPENSSL_SYSNAME_WIN32 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_ASM 
-DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5
OPENSSLDIR: "./."

OpenSSL 0.9.7 31 Dec 2002
built on: Thu Jan 23 09:44:10 2003
platform: VC-WIN32
options:  bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) idea(int) blowfis
h(idx)
compiler: cl  /MDd /W3 /WX /Zi /Yd /Od /nologo -DOPENSSL_SYSNAME_WIN32 -D_DEBUG
-DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DDEBUG -DDSO_WIN32 -DBN_ASM -DMD5_ASM -DSHA1_A
SM -DRMD160_ASM /Fdout32dll -DOPENSSL_NO_KRB5
OPENSSLDIR: "./."


and a stack trace:

_free_dbg_lk(void * 0x5000, int 1) line 1044 + 48 bytes
_free_dbg(void * 0x5000, int 1) line 1001 + 13 bytes
free(void * 0x5000) line 956 + 11 bytes
CRYPTO_free(void * 0x5000) line 364 + 10 bytes
ASN1_STRING_free(asn1_string_st * 0x) line 390 + 21 bytes
ASN1_primitive_free(ASN1_VALUE_st * * 0x00fd32f4, const ASN1_ITEM_st * 0x004df078 
local_it) line 224 + 11 bytes
asn1_item_combine_free(ASN1_VALUE_st * * 0x00fd32f4, const ASN1_ITEM_st * 0x004df078 
local_it, int 0) line 100 + 13 bytes
ASN1_template_free(ASN1_VALUE_st * * 0x00fd32f4, const ASN1_TEMPLATE_st * 0x004df7f4) 
line 175 + 28 bytes
asn1_item_combine_free(ASN1_VALUE_st * * 0x0076f31c, const ASN1_ITEM_st * 0x004df850 
local_it, int 0) line 151 + 13 bytes
ASN1_item_free(ASN1_VALUE_st * 0x00fd32f0, const ASN1_ITEM_st * 0x004df850 local_it) 
line 71 + 15 bytes
X509_NAME_ENTRY_free(X509_name_entry_st * 0x00fd32f0) line 78 + 18 bytes
sk_pop_free(stack_st * 0x00fe0860, void (void *)* 0x0046b597 
X509_NAME_ENTRY_free(X509_name_entry_st *)) line 290 + 16 bytes
x509_name_ex_free(ASN1_VALUE_st * * 0x00fdf66c, const ASN1_ITEM_st * 0x004df8b0 
local_it) line 144 + 16 bytes
asn1_item_combine_free(ASN1_VALUE_st * * 0x00fdf66c, const ASN1_ITEM_st * 0x004df8b0 
local_it, int 0) line 130 + 29 bytes
ASN1_template_free(ASN1_VALUE_st * * 0x00fdf66c, const ASN1_TEMPLATE_st * 0x004decc4) 
line 175 + 28 bytes
asn1_item_combine_free(ASN1_VALUE_st * * 0x00fdf6c0, const ASN1_ITEM_st * 0x004deda8 
local_it, int 0) line 151 + 13 bytes
ASN1_template_free(ASN1_VALUE_st * * 0x00fdf6c0, const ASN1_TEMPLATE_st * 0x004ded68 
X509_seq_tt) line 175 + 28 bytes
asn1_item_combine_free(ASN1_VALUE_st * * 0x0076f44c, const ASN1_ITEM_st * 0x004dedc8 
local_it, int 0) line 151 + 13 bytes
ASN1_item_free(ASN1_VALUE_st * 0x00fdf6c0, const ASN1_ITEM_st * 0x004dedc8 local_it) 
line 71 + 15 bytes
X509_free(x509_st * 0x00fdf6c0) line 125 + 18 bytes
sk_pop_free(stack_st * 0x00fdc470, void (void *)* 0x0045441c X509_free(x509_st *)) 
line 290 + 16 bytes
ca_main(int 0, char * * 0x00fb06c8) line 1636 + 17 bytes
do_cmd(lhash_st * 0x00fd2c80, int 9, char * * 0x00fb06a4) line 379 + 14 bytes
main(int 9, char * * 0x00fb06a4) line 298 + 20 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! bff8b560()
KERNEL32! bff8b412()
KERNEL32! bff89dd5()


And (while i'm at it) another thing to mention:
I'm using openssl with stunnel.
When i'm running stunnel as a service,  RAND_poll in rand_win.c can't work, as
it needs features not available under the SYSTEM account without a user logged in
(i.e. the UI features) so it dropped all the stuff except for the CryptAcquireContext 
when
building the "service version". Although i'm totally dependent on MS-randomness now,
everything works fine when runing as service now.

And yet another thing:
Usage of RAND_file_name() isn't working for a service-app with no logged-on user, too,
when no filename is specified. After trying to get a filename from the environment
(where none is defined), filename is filled with rubbish
(could be that the environment is rubbish, or the OS...).
So i don't use that under Win32 either.


Just wanted to mention those,
thanks a lot, best regards,

Claudius Thomas






__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Secure Messaging Non-Delivery Report: [openssl.org #481] (0.9.7 on Win32) openssl ca crashes when exiting...

[[EMAIL PROTECTED] via RT]

## Created by TFS ##
When [EMAIL PROTECTED] sent e-mail to
[EMAIL PROTECTED] (1/1/2)
Explanation: You have sent an e-mail that has been denied do to the Content Type  in 
this message.
#

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #435] ssl_connect core dump problem, with gdb traces

[[EMAIL PROTECTED] via RT]

Hi

Our's is a Proxy Server SSL enabled multithreaded application.
We are running on solaris operating system.
we are using OpenSSL library [ openssl-0.9.6 ]
we have serverCA and root CA certificate at the Proxy server application.
our application dumps in "ssl_connect" during certificate chain
verification.
Here the Certificate chain is Root CA---> ServerCA - server

What all certficates do we need at the proxy server application to validate
the above certificate chain.

The  gdb traces are as follows.

#0  0x0039d424 in X509_NAME_cmp (a=0x14291d0, b=0x1404c18) at
x509_cmp.c:173
173 j=na->value->length-nb->value->length;
(gdb) bt
#0  0x0039d424 in X509_NAME_cmp (a=0x14291d0, b=0x1404c18) at
x509_cmp.c:173
#1  0x003b14fc in X509_check_issued (issuer=0x7a5fb8, subject=0x6bbea8) at
v3_purp.c:528
#2  0x0039eca0 in check_issued (ctx=0xfe8075d8, x=0x6bbea8,
issuer=0x7a5fb8) at x509_vfy.c:339
#3  0x003a2728 in X509_STORE_CTX_get1_issuer (issuer=0xfe807560,
ctx=0xfe8075d8, x=0x6bbea8) at x509_lu.c:500
#4  0x0039e87c in X509_verify_cert (ctx=0xfe8075d8) at x509_vfy.c:243
#5  0x00355e64 in ssl_verify_cert_chain (s=0x8a2498, sk=0x5ae238) at
ssl_cert.c:472
#6  0x00364218 in ssl3_get_server_certificate (s=0x8a2498) at s3_clnt.c:832
#7  0x0036298c in ssl3_connect (s=0x8a2498) at s3_clnt.c:268
#8  0x00350fe0 in SSL_connect (s=0x8a2498) at ssl_lib.c:718
#9  0x000cc4a0 in Sdf_cl_NetworkManager::sslConnect (this=0x5f5c50,
pConnMapElem=0x1a46c20, pErr=0xfe807b30)
at source/networkmanager/src/sdftlsnetwork.cpp:1565
#10 0x000cb4b8 in Sdf_cl_NetworkManager::tlsSelectThread (this=0x5f5c50)
at source/networkmanager/src/sdftlsnetwork.cpp:1015
#11 0x000c9ed0 in Sdf_fn_startTlsSelectThread (pParam=0x5f5c50)
at source/networkmanager/src/sdftlsnetwork.cpp:199
Current language:  auto; currently c



Can anyone help us in figuring out the problem. (reason for core dump).

Thanks in Advance
Ajay Kumar










This message is proprietary to Hughes Software Systems Limited (HSS) and is
intended solely for the use of the individual to whom it is addressed.  It
may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.  If
you have received this message in error, please notify the originator
immediately.  If you are not the intended recipient, you are notified that
you are strictly prohibited from using, copying, altering, or disclosing
the contents of this message.  HSS accepts no responsibility for loss or
damage arising from the use of the information transmitted by this email
including damage from virus.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

> It's not supposed to.  It's only under unusual circumstances that this
> needs updating, and it should be done in the original source directory anyway.

> [[EMAIL PROTECTED] - Mon Jan 27 19:48:27 2003]:

> > In the original 0.9.7 release there also seems to be some
> > configuration
> > remnants left in the crypto/objects directory -- obj_dat.h;   this
> > isn't
> > removed by a "make clean".
> > 
> > \nick
> > 
> > 

When the links were made, because that file was there, there was a link back into the 
source directory.   The source directory was on a read-only file system.   The make 
process tried to rebuild the file and couldn't.   I haven't looked at why make thought 
it needed to rerun the perl script to rebuild obj_dat.h.

\nick

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #437] bad instructions in CHANGES for platform-dependent builds

[[EMAIL PROTECTED] via RT]

I suspect it doesn't really matter if the links are made only for files that are not 
already links.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #481] Rand()ing on Win32

[[EMAIL PROTECTED] via RT]

[[EMAIL PROTECTED] - Thu Jan 30 20:06:53 2003]:

First of all apologies for mixing several problems in one
post - i promise to do better next time, but i didn't consider
the Rand-problems bugs and really just wanted to mention them
on the side (having solved them for my purposes anyways)
as a hint for others.

> 
> That's a bit coarse.   It might be sufficient to allow the service to
>interact with the desktop [interactive user] (as admin user, right
>click on "My Computer", select Manage..., navigate to the services
>section, right click on the indicated service, choose the "Log On"
>tab, and under the radio button for "Local System account" there's
>a checkbox (off by default): "Allow service to interact with
>desktop".   This can also be enabled when the service registers
>itself at installation.
> 
> See MS Knowledge Base article number 115825 (formerly Q115825), as
>well as the documentation on ::CreateService() and search for
>SERVICE_INTERACTIVE_PROCESS.
> 

What's the use of allowing interaction with a pretty boring
desktop which always looks the same and has no "Mouse action"
for the purpose of generating randomness while introducing
a security risk ?

> 
> Of course some customer locations might be reticent about letting
>services interact with the desktop, this being a potential security
>hole.
> 
> But is there a bug here?  If it runs "okay" (with limited
>functionality) if the service doesn't have permissions to access
>the desktop, isn't that correct?  What would you have it do
>differently if it did detect that it was running as a service?  Is
>there some alternative source of randomness?  (Perhaps the number
>of patches applied to the system? :-).

That would at least give us a high number... :-)
The problem is the following:
I was just compiling stunnel for use as service and had to
get it running in a pretty short amount of time.
Both calls (Rand_poll and RAND_file_name without a specified file)
just had the effect that the service couldn't start up on
system startup.
You would only get a message that the system was unable to start
up the service (for a million seconds or so), before giving up.
I do not consider that a real bug, but it prevents usage
of openSSL within such a service "out of the box".
(It does not run "okay" then, otherwise i wouldn't have
mentioned it)

> 
> If so, it might be best to detect the problem at the specific API call
>that fails rather than decide based on running as a service --
>partly because it might work running as a service, partly because
>it might fail for other reasons when not running as a service.
> 

I did not have the time to really dive deep into problems,
so i was happy just being able to get everything running by
just modifying Rand_poll and skipping the Rand_file_name call
in stunnel.
For Rand_poll i found it sufficient to leave out all stuff
except for MS-randomness, epecially as the screen and user
stuff doesn't seem to make much sense under the aforementioned
circumstances anyways.
If the number of system patches is considered in the MS-algorithm
i can live with that randomness for the time being ;-)
Not giving a Rand_file_name and skipping the function was
o.k. for me too, as i don't have an "external" source of
randomness on the systems i use stunnel on.

If i have the time i'll try to come up with a good way to
determine if beeing run as service, while i for myself
can live with making that decision at compile-time at the
moment.
I'll also see if i can clarify the "rubbish" that comes up
in filename after usage of Rand_file_name without
filename and with no environment-variables set.
The only thing i can say so far is that it definitely
didn't even look slightly similar to something like ".rnd"
(more like the encrypted binary version of the word "rubbish")

I find it a bit tricky debugging a service at system startup
without a remote debugger and leaving conditions
realistic and original, but i'll see...

Thanks a lot,
best reagards,

Claudius Thomas

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #481] detect if running as service...

[[EMAIL PROTECTED] via RT]

I haven't had the time to go into it, but here's code from
the MSDN VC++6 samples "MAPIDBG.C" that is said
to do just this and seems reasonable.
I'll test this some other time if there's interest.

#if defined( _WINNT)

/*++

Routine Description:

This routine returns if the service specified is running interactively
(not invoked \by the service controller).

Arguments:

None

Return Value:

BOOL - TRUE if the service is an EXE.


Note:

--*/

BOOL WINAPI IsDBGServiceAnExe( VOID )
{
HANDLE hProcessToken = NULL;
DWORD groupLength = 50;

PTOKEN_GROUPS groupInfo = (PTOKEN_GROUPS)LocalAlloc(0, 
groupLength);

SID_IDENTIFIER_AUTHORITY siaNt = SECURITY_NT_AUTHORITY;
PSID InteractiveSid = NULL;
PSID ServiceSid = NULL;
DWORD i;

// Start with assumption that process is an EXE, not a Service.
BOOL fExe = TRUE;


if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, 
&hProcessToken))
goto ret;

if (groupInfo == NULL)
goto ret;

if (!GetTokenInformation(hProcessToken, TokenGroups, groupInfo,
groupLength, &groupLength))
{
if (GetLastError() != ERROR_INSUFFICIENT_BUFFER)
goto ret;

LocalFree(groupInfo);
groupInfo = NULL;

groupInfo = (PTOKEN_GROUPS)LocalAlloc(0, groupLength);

if (groupInfo == NULL)
goto ret;

if (!GetTokenInformation(hProcessToken, TokenGroups, groupInfo,
groupLength, &groupLength))
{
goto ret;
}
}

//
//  We now know the groups associated with this token.  We want to look to 
see if
//  the interactive group is active in the token, and if so, we know that
//  this is an interactive process.
//
//  We also look for the "service" SID, and if it's present, we know we're a 
service.
//
//  The service SID will be present iff the service is running in a
//  user account (and was invoked by the service controller).
//


if (!AllocateAndInitializeSid(&siaNt, 1, SECURITY_INTERACTIVE_RID, 0, 
0,
0, 0, 0, 0, 0, &InteractiveSid))
{
goto ret;
}

if (!AllocateAndInitializeSid(&siaNt, 1, SECURITY_SERVICE_RID, 0, 0, 0,
0, 0, 0, 0, &ServiceSid))
{
goto ret;
}

for (i = 0; i < groupInfo->GroupCount ; i += 1)
{
SID_AND_ATTRIBUTES sanda = groupInfo->Groups[i];
PSID Sid = sanda.Sid;

//
//  Check to see if the group we're looking at is one of
//  the 2 groups we're interested in.
//

if (EqualSid(Sid, InteractiveSid))
{
//
//  This process has the Interactive SID in its
//  token.  This means that the process is running as
//  an EXE.
//
goto ret;
}
else if (EqualSid(Sid, ServiceSid))
{
//
//  This process has the Service SID in its
//  token.  This means that the process is running as
//  a service running in a user account.
//
fExe = FALSE;
goto ret;
}
}

//
//  Neither Interactive or Service was present in the current users token,
//  This implies that the process is running as a service, most likely
//  running as LocalSystem.
//
fExe = FALSE;

ret:

if (InteractiveSid)
FreeSid(InteractiveSid);

if (ServiceSid)
FreeSid(ServiceSid);

if (groupInfo)
LocalFree(groupInfo);

if (hProcessToken)
CloseHandle(hProcessToken);

return(fExe);
}

#endif

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #474] Status Changed to: open

[[EMAIL PROTECTED] via RT]

We found some serious build issues with the original submission
(openssl-lunaca3-patch-0.9.7.tar.gz) and we are busy updating the patch.  I
expect the update will be necessary before this ticket is closed.

Let me know when you have the chance to examine the update and/or if I
should just post it.


Regards,

Steve Woloszyn 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #474] [PATCH] Crypto Engine Support for Chrysali s-ITS

[[EMAIL PROTECTED] via RT]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #524] DES/CBC question

[[EMAIL PROTECTED] via RT]

I don't like to send my questions to [EMAIL PROTECTED] as this doesn't look like a 
bug.  But my mail doesn't seem like getting through with user and dev emails...
==

Hi,

I am developing a cipher encryption tool in c++ using your openssl-crypto library.

The result encrypted string is passed to another system for decryption and vice versa, 
in which the cipher encryption tool was developed in Java, cipher algorithm is DES, 
mode is CBC, PKCS 5 padding.

I tried both functions DES_ncbc_encrypt() and DES_cbc_encrypt() in lib crypto/des for 
encryption, the result string can't be decrypted by the Java version cipher tool, it 
doesn't work the other way around neither. I got around the padding but the strings 
just look totally different.  Am I using the wrong functions? Which function provides 
the same algorithm/mode as the one we used in our Java version.

 Please help!! Thanks.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl

[[EMAIL PROTECTED] via RT]

Hi
building openssl under Solaris 2.6 (probably also other versions)
fails when linking the executable apps/openssl because library
flags -lxnet -lnsl are missing (needed for socket(), connect(), etc...)
Arto

openssl version:  0.9.7a
solaris version:  2.6
compiler version: gcc-3.1.1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #536] Bug in kssl ?

[[EMAIL PROTECTED] via RT]

I use openssl 0.9.7a with MIT Kerberos 1.2.4 and try to use Kerberos 
authentication/encryption. To test the functionality I tried ssltest as shown 
below. I run Suse 8.1 with 
uname -a
Linux moelma 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown


No kinit ssltest failed as expected.

./ssltest -v -d -cipher EXP-KRB5-DES-CBC-MD5
client waiting in SSL_connect - before/connect initialization
ERROR in CLIENT
7703:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers 
available:s23_clnt.c:274:


moelma:/usr/src/packages/SOURCES/openssl-0.9.7a/test # kinit moelma
Password for [EMAIL PROTECTED]:

After kinit ssltest starts and core dumps in kssl_build_principal_2

moelma:/usr/src/packages/SOURCES/openssl-0.9.7a/test # ./ssltest -v -d -cipher 
EXP-KRB5-DES-CBC-MD5
client waiting in SSL_connect - before/connect initialization
server waiting in SSL_accept - before/accept initialization
client waiting in SSL_connect - SSLv2/v3 read server hello A
server waiting in SSL_accept - SSLv3 read client certificate A
Segmentation fault


Is this a bug or did I miss something ?

Markus

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #521] [PATCH] Avoid uninitialized data in random buffer

[[EMAIL PROTECTED] via RT]

I think there's we need to create a FAQ entry about this ...

* Daniel Brahneborg ([EMAIL PROTECTED]) wrote:

[snip]

> At lines 467-469 in crypto/rand/md_rand.c is an interesting
> thing:
> 
> #ifndef PURIFY
> MD_Update(&m,buf,j); /* purify complains */
> #endif
> 
> That is the code that causes the problem (I just verified
> it with Valgrind).  Does it have any bad side affects to
> always skip that code?  Since both Purify and Valgrind is
> unhappy with that function call, something must be wrong
> with it.

No, it's fine - the problem is Purify and Valgrind assume all use of
uninitialised data is inherently bad, whereas a PRNG implementation has
nothing but positive (or more correctly, non-negative) things to say
about the idea.

Why do you think the "#ifndef PURIFY" logic is there?

If you're going to run an openssl-based app under instrumentation and
*look* for uses of uninitialised data, add "-DPURIFY" to your configure
line. Please also search the archives for words like "Valgrind",
"Purify", "uninitialised memory", etc. This has come up many times
before.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #540] Changes in config

[[EMAIL PROTECTED] via RT]

OpenSSL version 0.9.7a
AIX version 4.3.3 ML10

AIX does NOT respond "command not found" when a command can't be found.
It respond with "ksh: cc: not found.".

Change line 461 in config
(cc) 2>&1 | grep -iv "not found" > /dev/null && CC=cc




Hälsningar / Regards

Kent Thureson
CAE System Supervisor
*Lear Corporation Sweden AB
Box 942
Installatörvägen 21
SE-461 29  Trollhättan
Sweden
__
Desk phone: +46 (0)520 48 51 21
Fax   : +46 (0)520 48 54 97
Mobile: +46 (0)704 28 68 52
E-mail:  [EMAIL PROTECTED]

Thureson, Kent
Email address: [EMAIL PROTECTED]

Lear Corporation Sweden

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #539] bug in openssl 0.9.7 (all OSes), in EVP_??cryptInit

[[EMAIL PROTECTED] via RT]

Openssl bugs administrator,
 
I believe I found a bug in EVP_DecryptInit and EVP_EncryptInit. The
documentation at: http://www.openssl.org/docs/crypto/EVP_EncryptInit.html
says that those two functions and EVP_CipherInit do not need the
EVP_CIPHER_CTX to be initialized, but that is not true. Only 
EVP_CipherInit allows the EVP_CIPHER_CTX to be un-initialized. You can see
the problem in openssl-0.9.7/crypto/evp/evp_enc.c, line 227 and 239. They
should call the non-_ex functions, but do not. This causes an
un-initialized CTX to be used without an init, which usually causes a
segfault. Here is a test program that shows the problem:
 
#include 
#include 
 
int main( int argc, char *argv[] )
{
  EVP_CIPHER_CTX x;
  char key[32], iv[16];
 
printf( "memset(0) works...\n" );
  memset( &x, 0, sizeof(x) );
  EVP_DecryptInit( &x, EVP_aes_256_cbc(), key, iv );
 
printf( "memset(0xff) fails...\n" );
  memset( &x, 0xff, sizeof(x) );
  EVP_DecryptInit( &x, EVP_aes_256_cbc(), key, iv );
 
printf( "does not get here\n" );
  return 0;
}
 
My output is:
 
memset(0) works...
memset(0xff) fails...
Segmentation fault
 
To fix, just change evp_enc.c to call EVP_CipherInit instead of
EVP_CipherInit_ex on lines 227 and 239.

If you have any questions, please contact me.
 
Thank you,
 
Noah Gintis.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #542] 0.9.7a: doc/apps/pod page omissions

[[EMAIL PROTECTED] via RT]

doc/apps/s_client.pod:  The following command option is not mentioned

 -starttls prot - use the STARTTLS command before starting TLS
 for those protocols that support it, where 'prot'
 defines which one to assume. Currently, only "smtp"
 is supported.



doc/apps/s_server.pod:  The following command option is not mentioned

 -id_prefix arg - Generate SSL/TLS session IDs prefixed by 'arg'





OpenSSL self-test report:

OpenSSL version:  0.9.7a
Last change:  In ssl3_get_record (ssl/s3_pkt.c), minimize
information...
Options:  no-krb5
OS (uname):   Linux test 2.4.20 #16 Sun Mar  9 01:57:21 GMT 2003 i686
unknown
OS (config):  i686-whatever-linux2
Target (default): linux-elf
Target:   linux-elf
Compiler: gcc version 2.95.2 19991024 (release)

Test passed.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl

[[EMAIL PROTECTED] via RT]

Hi
just checked: yes, all 3 flags (-lsocket -lnsl -ldl) are missing.
-lsocket and -ldl seem not needed, anyway (ldd openssl also shows
that they are absent, but ./openssl still runs).
Only -lxnet and -lnsl are necessary. When adding these
to the compiler flags, it works. Probably have done
it during configure, but can't remember anymore. In any case,
now, with these flags added, after deleting target apps/openssl and
re-running a gmake, it compiles with the following options (without
the 3 library flags you mentioned; the string
-fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl
is from my usual compiler flags where I must have added
-lxnet -lnsl at some stage):

  gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 
-fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -fPIC -O3 -msupersparc -Qn -Wa,-Qn 
-fno-ident -s -lxnet -lnsl -o openssl -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS  
-DOPENSSL_NO_KRB5  openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o 
passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o 
x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o 
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o 
smime.o rand.o engine.o ocsp.o  -L.. -lssl  -L.. -lcrypto  ; \

Arto


- Begin Included Message -

Date: Thu, 20 Mar 2003 12:24:00 +0100 (MET)
From: Richard Levitte via RT <[EMAIL PROTECTED]>
Subject: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl
In-reply-to: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Interesting, since all our Solaris targets have "-lsocket -lnsl -ldl" as extra linking 
flags...  So just to check, is -lnsl really missing in your builds, or is it just 
-lxnet?

[EMAIL PROTECTED] - Wed Mar  5 14:00:08 2003]:

> Hi
> building openssl under Solaris 2.6 (probably also other versions)
> fails when linking the executable apps/openssl because library
> flags -lxnet -lnsl are missing (needed for socket(), connect(), etc...)
> Arto
> 
> openssl version:  0.9.7a
> solaris version:  2.6
> compiler version: gcc-3.1.1
> 


-- 
Richard Levitte
[EMAIL PROTECTED]


- End Included Message -

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

2nd Re: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl

[[EMAIL PROTECTED] via RT]

Hey, just found the script with which I seem to have
successfully generated openssl in the end, confirming
my email from just a few minutes ago:

-
#!/bin/csh

./Configure solaris-sparcv8:"gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W 
-fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl"

gmake
-

Arto


- Previous Message -

Hi
just checked: yes, all 3 flags (-lsocket -lnsl -ldl) are missing.
-lsocket and -ldl seem not needed, anyway (ldd openssl also shows
that they are absent, but ./openssl still runs).
Only -lxnet and -lnsl are necessary. When adding these
to the compiler flags, it works. Probably have done
it during configure, but can't remember anymore. In any case,
now, with these flags added, after deleting target apps/openssl and
re-running a gmake, it compiles with the following options (without
the 3 library flags you mentioned; the string
-fPIC -O3 -msupersparc -Qn -Wa,-Qn -fno-ident -s -lxnet -lnsl
is from my usual compiler flags where I must have added
-lxnet -lnsl at some stage):

  gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 
-fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -fPIC -O3 -msupersparc -Qn -Wa,-Qn 
-fno-ident -s -lxnet -lnsl -o openssl -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS  
-DOPENSSL_NO_KRB5  openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o 
passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o 
x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o 
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o 
smime.o rand.o engine.o ocsp.o  -L.. -lssl  -L.. -lcrypto  ; \

Arto


- Begin Included Message -

Date: Thu, 20 Mar 2003 12:24:00 +0100 (MET)
From: Richard Levitte via RT <[EMAIL PROTECTED]>
Subject: [openssl.org #527] openssl-0.9.7a under Solaris needs -lxnet -lnsl
In-reply-to: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Interesting, since all our Solaris targets have "-lsocket -lnsl -ldl" as extra linking 
flags...  So just to check, is -lnsl really missing in your builds, or is it just 
-lxnet?

[EMAIL PROTECTED] - Wed Mar  5 14:00:08 2003]:

> Hi
> building openssl under Solaris 2.6 (probably also other versions)
> fails when linking the executable apps/openssl because library
> flags -lxnet -lnsl are missing (needed for socket(), connect(), etc...)
> Arto
> 
> openssl version:  0.9.7a
> solaris version:  2.6
> compiler version: gcc-3.1.1
> 


-- 
Richard Levitte
[EMAIL PROTECTED]


- End Included Message -

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #543] Valid trick to reduce session object's size?

[[EMAIL PROTECTED] via RT]

Hello,

I wrote an SSL tunnel application, which works with client-autentication:
clients must present a certificate signed by an approved CA to use this tunnel.

The number of clients using system could be quite large, and session-resumption
is obviously important to support.

One thing that has been bothering me about the session cache is that when
client-authentication is enabled, a session object takes a much larger
amount of memory - as much as 10 times more than a session without client
authentication. I did a little research and found that the problem is that
the client certificate (whose size is as much as 1K) is kept in the session
object, and therefore also in the session cache.

I can understand why a general-purpose server might want to keep those
certificate around for session resumptions, but for my purposes (and probably
for the purposes of many other people), this is completely unnecessary: once
the client is verified to be authorized to use the tunnel, I no longer care
to remember any details of who this specific client is.

I think I found a solution for this, but I'm not sure how safe is what I've
done so I'd appreciate comments, or ideas on how to do this better.

My idea is that after the handshake completes successfully (and the client
is authenticated) we can free the peer certificates. We must do it before
a copy of the session is saved in the external session cache, so the proper
place to do it is in the new-session callback (see SSL_CTX_sess_set_get_cb(3))
which is called right after a handshake completes and when the session is
ready to be put in the external session cache.

But how do I free the peer certificate? One thing was farely obvious - I did

if(s->session->peer){
X509_free(s->session->peer);
s->session->peer=0;
}

Which frees the client's certificate. I believe this is safe to do from the
new-session callback (but I'd appreciate any comments), and it makes the
memory use of the external session cache much smaller (in my case).

However, I noticed there's another field that contains certificates coming
from the clients: s->session->sess_cert->cert_chain. I thought it contains
the rest of the certificate chain (all except the last one, which is put
in s->session->peer), and that it could be freed safely as well. But
unfortunately, I did not find a clean way to do that - I only found how
to free s->session->sess_cert (relatively) cleanly, by doing

/* eek, this function is defined in ssl_locl.h, not ssl.h... */
extern void ssl_sess_cert_free(void *);

if (s->session->sess_cert){
ssl_sess_cert_free(s->session->sess_cert);
s->session->sess_cert=0;
}

But I was wondering, is it safe to do (again, assuming I will not be
interested in the client's identity for the rest of the session)?
Or does the s->session_sess_cert contain any important data that I
shouldn't free like that?

I verified that freeing both the session->peer and session->sess_cert
actually does works (and session resumes, etc., continue to work) but
what I would like is some reassurance that what I did is "safe", and
that there isn't a simpler or cleaner way to do this.

In fact, it would have been nice if it were possible to turn on a flag
for OpenSSL, which will tell it that it can discard the client certificate
(and everything related to it) immediately after its verification.
I didn't see such an option existing.

Thanks for any ideas or thoughts,
Nadav.

-- 
Nadav Har'El|  Wednesday, Mar 19 2003, 16 Adar II 5763
[EMAIL PROTECTED] |-
Phone: +972-53-245868, ICQ 13349191 |I couldn't afford a cool signature, so I
http://nadav.harel.org.il   |just got this one.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #543] Valid trick to reduce session object's size?

[[EMAIL PROTECTED] via RT]

On Sun, Mar 23, 2003, Lutz Jaenicke wrote about "Re: Valid trick to reduce session 
object's size?":
> As far as I can see, there is no problem with your approach. One obvious
> downside is, that you lose the information about the client (but you
> already said that you don't care). The other downside is, that you don't
> know whether the client authenticated at all. This is no problem as long

Right. In my setup, all clients will have to authenticate, and once they
do they will get access to the service, regardless of who they authenticated
as.

If it was important for me to remember whether the client authenticated or
not (had I allowed that), or who the client is, I could have saved a bit
more information before deleting the certificates. The certificates
themselves are pretty big (several kilobytes) relative to the few bytes of
information I will ever need from them again. But so far I don't need to
even save that information.

> Hmm. Do you use internal or external session caching? The cert_chain is
> not maintained when storing to the external session cache; thus it is
> only a problem if you are talking about a large internal cache.

I currently use both (as do most SSL servers, like Apache, by the way).
You're right, the cert_chain is only saved in the internal cache (there are
even nice comments in the OpenSSL code reminding of this fact :)), but the
internal cache can also get quite big. In fact by default it saves 20,000
sessions, which with client authentication comes out huge.

Maybe I've done a judgement error, and I should not be using on a large
internal cache, but instead drop the internal cache completely and use
just the external one (thanks to the new SSL_SESS_CACHE_NO_INTERNAL!).
But for various silly reasons I am temporarily using the internal cache too,
and I wanted my get-rid-of-the-client-certificates hack to be complete.

> > In fact, it would have been nice if it were possible to turn on a flag
> > for OpenSSL, which will tell it that it can discard the client certificate
> > (and everything related to it) immediately after its verification.
> > I didn't see such an option existing.
> 
> There is no such option. And I indeed believe, that it is a more or less
> unusual request (typically people are interested in obtaining the
> information about the peer, as this is what authentication is about).
> That does not mean, that one could not implement it, if there is enough
> public interest...

Since this is just an issue of memory use, and not a new feature, I guess
most people won't even notice that they are missing this feature - they
would just go out and buy more memory.
I really have no idea if anybody else needs this feature - I just thought
it would be nice for my needs and wanted comments if I did it correctly :)

By the way, if other people are interested, but not enough to add this as
an official session option, an alternative could be to add a function
(say, SSL_SESSION_free_certificates) that the programmer would have to call
explicitly (the manual page could explain from where). This will save the
programmer the need to access internal structures and "extern" strange
routines, like I did. But again, if nobody else requested this functionality,
feel free to stick this idea in the "when pigs fly" drawer :)

Thanks,
Nadav.

-- 
Nadav Har'El| Sunday, Mar 23 2003, 20 Adar II 5763
[EMAIL PROTECTED] |-
Phone: +972-53-245868, ICQ 13349191 |Take my advice, I don't use it anyway.
http://nadav.harel.org.il   |
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #528]

[[EMAIL PROTECTED] via RT]

>I think I've fixed the problem.  Please try tomorrows snapshot and 
>tell me how it worked.
>
>[guest - Thu Mar  6 15:34:46 2003]:
>
>>  Solaris 8 [SPARC]
>>  gcc 3.3.2
>>  openssl 0.9.7a
>>
>>  Using
>>
>>  ./config
>>
>>  everything works as expected, however with
>>
>>  ./config shared
>>
>>  make test fails as we use LD_LIBRARY_PATH
>>
>>  The Makefiles in ./ and ./tests set LD_LIBRARY_PATH to `pwd`
>>  rather than  `pwd`:$$LD_LIBRARY_PATH
>>
>>  Is this a bug or an error on my part
>>
>>
>>  many thanks
>  >
>  > iain morrison
>  >
>  > [EMAIL PROTECTED]
>  >
>
>
>--
>Richard Levitte
>[EMAIL PROTECTED]

Hi richard,
   sorry for the delay - weve been rewiring our machine room!


Using openssl-0.9.7-stable-SNAP-20030323 things are much better
but still not quite right on our system


./config shared
make
make test

All the tests run fine until the final apps/openssl version -a


make[1]: Leaving directory 
`/usr/local/src/openssl/openssl-0.9.7-stable-SNAP-20030323/test'
ld.so.1: apps/openssl: fatal: libgcc_s.so.1: open failed: No such 
file or directory
Killed
make: *** [tests] Error 137

running this afterwards gives

apps/openssl version -a
OpenSSL 0.9.7a Feb 19 2003
built on: Wed Mar  5 20:57:19 GMT 2003
platform: solaris-sparcv9-gcc
options:  bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) 
idea(int) blowfish(ptr)
compiler: gcc -DOPENSSL_SYSNAME_ULTRASPARC -fPIC -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -m32 
-mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W 
-DMD5_ASM
OPENSSLDIR: "/usr/local/ssl"


so I suspect that LD_LIBRARY_PATH isnt being set correctly.


If I can run any tests/diagnostics for you please let me know

ta

iain
-- 

--
Iain Morrison
MRC Cognition and Brain Sciences Unit
15 Chaucer Road  Tel   01223 355294 xt 581
CambridgeFax   01223 359062
CB2 2EF
  email [EMAIL PROTECTED]
--

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #547] SSL_CTX_free messes with external session cache

[[EMAIL PROTECTED] via RT]

Hi,

I noticed that SSL_CTX_free() takes all the sessions in the given CTX's
internal session cache, and also removes them from the external session cache
(i.e., calls the delete-session callback).

Why was this done? I can't think of a security or a logical explanation to
this, because these sessions in the external cache are still valid, and other
contexts or processes might still want to reuse them!

Looking at the SSL_CTX_free() code (ssl/ssl_lib.c), I see that
SSL_CTX_flush_sessions(a,0) is called - and from the manual page of
that function I understand that what this means is to mark sessions older
than time 0 (i.e., all sessions) as *expired*, and all these sessions
are also deleted from the external session cache. I don't understand why
this kind of behavior should be part of SSL_CTX_free().

By the way, it's relatively easy for me to overcome this behavior by
cancelling the delete-session callback before calling SSL_CTX_free() - but
I was wondering why I have to do that...



-- 
Nadav Har'El|  Wednesday, Mar 26 2003, 23 Adar II 5763
[EMAIL PROTECTED] |-
Phone: +972-53-245868, ICQ 13349191 |The human mind is like a parachute - it
http://nadav.harel.org.il   |functions better when it is open.
__
OpenSSL Project http://www.openssl.org
User Support 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 #549] Enhancemant Request

[[EMAIL PROTECTED] via RT]

Could you add the setting of a credential cache through kssl_ctx_setstring as 
it is possible for KSSL_KEYTAB and use the value in kssl_tgt_is_available and
kssl_cget_tkt by changing it as indicated below: 

if ((krb5rc = krb5_cc_default(krb5context, &krb5ccdef)) != 0)
goto err;

to
 if (kssl_ctx->cred_cache) {
if ((krb5rc = krb5_cc_resolve(krb5context, kssl_ctx->cred_cache, 
&krb5ccdef)) != 0)
goto err;
 } else {   
if ((krb5rc = krb5_cc_default(krb5context, &krb5ccdef)) != 0)
goto err;
}

Thank you
Markus

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #528]

[[EMAIL PROTECTED] via RT]

>In message <[EMAIL PROTECTED]> on Tue, 25 Mar 
>2003 14:46:04 +0100 (MET), "[EMAIL PROTECTED] via RT" 
><[EMAIL PROTECTED]> said:
>
>rt> All the tests run fine until the final apps/openssl version -a
>rt>
>rt>
>rt> make[1]: Leaving directory
>rt> `/usr/local/src/openssl/openssl-0.9.7-stable-SNAP-2003032 3/test'
>rt> ld.so.1: apps/openssl: fatal: libgcc_s.so.1: open failed: No such
>rt> file or directory
>rt> Killed
>rt> make: *** [tests] Error 137
>
>Yup, I apparently forgot a few dollar signs.  Just committed a fix.
>Please try tomorrows snapshot.

Hi Richard,
   openssl-0.9.7-stable-SNAP-20030326 produced no errors

ta

iain



>--
>Richard Levitte   \ Spannv”gen 38, II \ [EMAIL PROTECTED]
>[EMAIL PROTECTED]  \ 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.


-- 

--
Iain Morrison
MRC Cognition and Brain Sciences Unit
15 Chaucer Road  Tel   01223 355294 xt 581
CambridgeFax   01223 359062
CB2 2EF
  email [EMAIL PROTECTED]
--

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #550] bug report - library and header version mismatch

[[EMAIL PROTECTED] via RT]

Hi Folks

I have noticed that the internal version number of of opensslv.h (0x0090701fL)
and the internal version number of libcrypto.so.0.9.7 and libssl.so.0.9.7 (0x0090700fL)
do not match for openssl-0.9.7a.

They also do not match in openssl-0.9.7-stable-SNAP-20030326.

This version mismatch is causing configuration of openssh-3.5p1 to fail
with the following error message:

checking OpenSSL header version... 90701f (OpenSSL 0.9.7a Feb 19 2003)
checking OpenSSL library version... 90700f (OpenSSL 0.9.7 31 Dec 2002)
checking whether OpenSSL's headers match the library... configure: error:
Your OpenSSL headers do not match your library

Here is the self-test report:


OpenSSL self-test report:

OpenSSL version:  0.9.7a
Last change:  In ssl3_get_record (ssl/s3_pkt.c), minimize
information...
Options:  --openssldir=/usr/local/OpenSSL threads shared no-krb5
OS (uname):   Linux dgrunt 2.4.20 #1 Wed Mar 19 13:10:00 EST 2003 i586
unknown
OS (config):  i586-whatever-linux2
Target (default): linux-k6
Target:   linux-k6
Compiler: gcc version 2.95.3 20010315 (release)

Test passed.

Test report in file testlog

What can I do to fix this?

Thanks
-- Ken --
[EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #551] [Fwd: Bug#186487: openssl: 'openssl ca' allows serial 00 which breaks the signed certificate]

[[EMAIL PROTECTED] via RT]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #552] [Fwd: Bug#186490: libssl0.9.7: EVP_{En,De}cryptFinal() don't free ctx parameter]

[[EMAIL PROTECTED] via RT]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #550] bug report - library and header version mismatch

[[EMAIL PROTECTED] via RT]

lib  conftest.c -lutil -l
z -lnsl  -lcrypto >&5
In file included from /usr/include/string.h:360,
 from configure:8681:
/usr/include/bits/string2.h: In function `__strcpy_small':
/usr/include/bits/string2.h:428: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:436: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:441: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:446: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:448: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:453: warning: pointer of type `void *' used in arithmetic
configure: In function `main':
configure:8683: warning: implicit declaration of function `SSLeay'
configure:8692: $? = 0
configure:8694: ./conftest
configure:8697: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 8679 "configure"
#include "confdefs.h"

#include 
#include 
int main(void) { exit(SSLeay() == OPENSSL_VERSION_NUMBER ? 0 : 1); }

configure:8709: result: no
configure:8711: error: Your OpenSSL headers do not match your library


It looks to me like the internal version numbers for libcrypto and libssl (as well as 
the static lib)
have not been updated correctly in the source.

BTW: openssl-0.9.7-stable-SNAP-20030326 has the same problem.

SO - now what should I do?

Thanks
-- Ken --

** Script follows **

#!/bin/sh
#
# getlibver.sh
#   Based on findssl.sh by Darren Tucker (dtucker at zip dot com dot au)
#   This file is placed in the public domain.
#

# findssl.sh
#   Search for all instances of OpenSSL headers and libraries
#   and print their versions.
#   Intended to help diagnose OpenSSH's "OpenSSL headers do not
#   match your library" errors.
#
#   Written by Darren Tucker (dtucker at zip dot com dot au)
#   This file is placed in the public domain.
#
#   2002-07-27: Initial release.
#   2002-08-04: Added public domain notice.
#   27 March 2003: Make it search in $1/* for opensslv.h, libcrypto.s*, libssl.s*
#

#
# Adjust these to suit your compiler
#
CC=gcc
STATIC=-static

#
# Set up conftest C source
#
rm -f findssl.log
cat >conftest.c <
int main(){printf("0x%08xL\n", SSLeay());}
EOD

#
# Search for OpenSSL headers and print versions
#
echo "Searching for and checking OpenSSL header files."
headers=`find $1 -follow -name opensslv.h -print 2>/dev/null`

for header in $headers
do
ver=`awk '/OPENSSL_VERSION_NUMBER/{printf \$3}' $header`
echo "$ver $header"
done
echo

#
# Search for shared libraries (libcrypto and libssl).
# Relies on shared libraries looking like "libcrypto.s*"
#
echo "Searching for and checking OpenSSL shared libraries (libcrypto.s*, libssl.s*)."
libraries=`find $1 -follow -name 'libcrypto.s*' -print 2>/dev/null`

for lib in $libraries
do
echo "Trying libcrypto $lib" >>findssl.log
${CC} -o conftest conftest.c $lib 2>>findssl.log
if [ -x ./conftest ]
then
ver=`./conftest 2>/dev/null`
rm -f ./conftest
echo "$ver $lib"
fi
done
echo

#

libraries=`find $1 -follow -name 'libssl.s*' -print 2>/dev/null`

for lib in $libraries
do
echo "Trying libssl $lib" >>findssl.log
${CC} -o conftest conftest.c $lib 2>>findssl.log
if [ -x ./conftest ]
then
ver=`./conftest 2>/dev/null`
rm -f ./conftest
echo "$ver $lib"
fi
done
echo
#
# Search for static OpenSSL libraries and print versions
#
echo "Searching for and checking OpenSSL static library files."
libraries=`find $1 -follow -name libcrypto.a -print 2>/dev/null`

for lib in $libraries
do
libdir=`dirname $lib`
echo "Trying libcrypto $lib" >>findssl.log
${CC} ${STATIC} -o conftest conftest.c -L${libdir} -lcrypto 2>>findssl.log
if [ -x ./conftest ]
then
ver=`./conftest 2>/dev/null`
rm -f ./conftest
echo "$ver $lib"
fi
done

#
# Clean up
#
rm -f conftest.c





On Thu, 27 Mar 2003, Richard Levitte - VMS Whacker via RT wrote:

>
> In message <[EMAIL PROTECTED]> on Thu, 27 Mar 2003 15:09:47 +0100 (MET), "[EMAIL 
> PROTECTED] via RT" <[EMAIL PROTECTED]> said:
>
> rt> I have noticed that the internal version number of of opensslv.h
> rt> (0x0090701fL) and the internal version number of
> rt> libcrypto.so.0.9.7 and libssl.so.0.9.7 (0x0090700fL)
> rt> do not match for openssl-0.9.7a.
>
> You're confused.  0x0090701fL doe

[openssl.org #549] patch for enhancement request

[[EMAIL PROTECTED] via RT]

I created a patch file for openssl 0.9.7a to allow the control of the kerberos 
credential cache.

Regards
Markus
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom

[[EMAIL PROTECTED] via RT]

Hello!

Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it
because the select
system call works different on AIX than on linux.

As described in the following URL, the select system call expects the
number
of file describtors as first parameter in AIX. Linux expects the highst
numbered
fd +1.

http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm


So I made a #ifdef and hardcoded the first parameter to 1 for AIX. I'm not
sure
if this will have any side effects, especially for versions < 5.2 but I
don't
think so.

The attached patch will do the change on the file
openssl-0.9.7a/crypto/rand/rand_unix.c.
Anders Liljegren tested it also on AIX 5.2 and found no problems.

Bye

  Andreas Walter


diff -u openssl-0.9.7a/crypto/rand/rand_unix.c-orig
openssl-0.9.7a/crypto/rand/rand_unix.c
--- openssl-0.9.7a/crypto/rand/rand_unix.c-orig 2003-03-28
14:23:01.0 +0100
+++ openssl-0.9.7a/crypto/rand/rand_unix.c  2003-03-28
14:45:19.0 +0100
@@ -170,7 +170,14 @@
FD_SET(fd, &fset);
r = -1;

+#ifdef AIX /* First paramater on AIX Specifies the number of file
descriptors and message
+* queues to check. See also:
+*
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm
+*/
+   if (select(1,&fset,NULL,NULL,&t) <
0)
+#else
if (select(fd+1,&fset,NULL,NULL,&t) < 0)
+#endif
t.tv_usec=0;
else if (FD_ISSET(fd, &fset))
{



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom

[[EMAIL PROTECTED] via RT]

Hi!

> No patch should be required, not even AIX can be that weird.  An
> official specification for select() is available at
>
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm


Ok, is it maybe a PEBKAC. But I cannot find an explanation for the
following behavior:

I use the little programm that Anders Liljegren mailed at
http://www.mail-archive.com/[EMAIL PROTECTED]/msg30771.html about 2
weeks ago.

#include 
#include 
#include 

int main(void)
{
exit(RAND_status());
}



Both times openssl is configured with ./Configure  aix43-gcc and compiled
with gcc-3.2.1
and the IBM linker. The first test is without the patch, the second with
the patch.

Any ideas?

  Andreas Walter


truss ./ssl-test
execve("./ssl-test", 0x2FF22BA4, 0x2FF22BAC) argc: 1
__loadx(0x0A04, 0xD03399AC, 0x0003, 0x1000, 0x2D1D) =
0x
_getpid()   = 22600
_getpid()   = 22600
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
_select(4, 0x2FF20A50, 0x, 0x, 0x2FF22A58) = 0
close(3)= 0
open("/dev/random", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
_select(4, 0x2FF20A50, 0x, 0x, 0x2FF22A58) = 0
close(3)= 0
open("/dev/srandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) Err#2  ENOENT
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 19)  Err#2  ENOENT
close(3)= 0
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 15)  Err#2  ENOENT
close(3)= 0
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 15)  Err#2  ENOENT
close(3)= 0
socket(1, 1, 0) = 3
connext(3, 0x2FF20850, 14)  Err#2  ENOENT
close(3)= 0
_getpid()   = 22600
sbrk(0x)= 0x2000B4A8
sbrk(0x0008)= 0x2000B4A8
sbrk(0x00010010)= 0x2000B4B0
getuidx(2)  = 0
_getpid()   = 22600
_getpid()   = 22600
kfcntl(1, F_GETFL, 0x20008F54)  = 2
kfcntl(2, F_GETFL, 0x)  = 2
_exit(0)



truss ./ssl-test-aixpatch
execve("./ssl-test-aixpatch", 0x2FF22B9C, 0x2FF22BA4)  argc: 1
__loadx(0x0A04, 0xD03399AC, 0x0003, 0x1000, 0x2D35) =
0x
_getpid()   = 24072
_getpid()   = 24072
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
_select(1, 0x2FF20A40, 0x, 0x, 0x2FF22A48) = 0
kread(3, " @ Z ??- G ?806 W V '".., 32)  = 32
close(3)= 0
_getpid()   = 24072
sbrk(0x)= 0x2000B4D4
sbrk(0x000C)= 0x2000B4D4
sbrk(0x00010010)= 0x2000B4E0
_getpid()   = 24072
getuidx(2)  = 0
_getpid()   = 24072
_getpid()   = 24072
kfcntl(1, F_GETFL, 0x20008F6C)  = 67110914
kfcntl(2, F_GETFL, 0x)  = 67110914
_exit(1)



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #563] RE : Problem Self signing certificate

[[EMAIL PROTECTED] via RT]

Hie

I was trying to sign my own certificates after setting up Openssl
on Linux 7.0. I download the latest tar.gz file and I installed everything
without a problem.

The problem arose when I tried ti self sign my certificates


I have attched a text file of the error reported. My you please assist to
solve this problem.

I was able to view it using Wordpad on my windows P.C.

Thanking you very much for you assistence.



regards

Gibson
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #640] bug: Makefile.ssl for do_srv3-shared and do_svr5-shared buggy

[[EMAIL PROTECTED] via RT]

Hi,

I have found that the "grep $$obj allobjs" in Makefile.ssl returns more entries 
than excepted. I am using 0.9.6j.

For example when processing mem.o the grep will return 2 entries: 
./crypto/bio/bss_mem.o and ./crypto/mem.o. That way unexcepted objects may end 
in the dynamic library.

The fix I see it to extract the content of the *.a file in a temporary 
subdirectory and fill the dynamic library with those objects.

Cheers

Jean-frederic

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #660] X509_STORE_CTX_init limits depth to 9

[[EMAIL PROTECTED] via RT]

It seems that X509_STORE_CTX_init arbitrarily limits the depth of the
cert chain that can be checked to 9 certificates. Is this a bug, feature
(dos prevention?) or just arbitrary? 
If it is a feature then it would be nice to provide a API call to modify
the default. I'll send a patch if such a thing would be accepted. 

/Sam

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #666] Optimization only with maximal -01

[[EMAIL PROTECTED] via RT]

Attached three testlog-Outputs

The Hint in INSTALL:

 If a test fails, look at the output.  There may be reasons for
 the failure that isn't a problem in OpenSSL itself (like a missing
 or malfunctioning bc).

>>   If it is a problem with OpenSSL itself,
>>   try removing any compiler optimization flags from the CFLAG
>>   line in Makefile.ssl and run "make clean; make".

 Please send a bug
 report to <[EMAIL PROTECTED]>, including the output of
 "make report" in order to be added to the request tracker at
 http://www.openssl.org/support/rt2.html.

helps fine.



MfG Klaus-Peter Kuppinger

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #680] minor bug in ssl3_send_certificate_request()

[[EMAIL PROTECTED] via RT]

In function ssl3_send_certificate_request(), the state
is never switched to SSL3_ST_SW_CERT_REQ_B after
the handshake message is serialized.

It's a fairly minor bug, with a simple fix:

#ifdef NETSCAPE_HANG_BUG
p=(unsigned char *)s->init_buf->data + s->init_num;

/* do the header */
*(p++)=SSL3_MT_SERVER_DONE;
*(p++)=0;
*(p++)=0;
*(p++)=0;
s->init_num += 4;
#endif

>
>   s->state = SSL3_ST_SW_CERT_REQ_B;
}

/* SSL3_ST_SW_CERT_REQ_B */
return(ssl3_do_write(s,SSL3_RT_HANDSHAKE));
err:
return(-1);
}

__
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 #679] minor bug in ssl3_send_client_verify()

[[EMAIL PROTECTED] via RT]

In function ssl3_send_client_verify(), the state
is never switched to SSL3_ST_CW_CERT_VRFY_B after
the handshake message is serialized.

It's a fairly minor bug:

*(d++)=SSL3_MT_CERTIFICATE_VERIFY;
l2n3(n,d);

s->init_num=(int)n+4;
s->init_off=0;
>
>   s->state=SSL3_ST_CW_CERT_VRFY_B;
}
return(ssl3_do_write(s,SSL3_RT_HANDSHAKE));
err:
return(-1);
}
__
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 #682]

[[EMAIL PROTECTED] via RT]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #684] Memory Leaks in RSA_eay_private_decrypt

[[EMAIL PROTECTED] via RT]

Hi

File: Crypto\RSA\rsa_eay.c
Function: RSA_eay_private_decrypt
Line: 430 (blinding = setup_blinding(rsa, ctx);)

The flag 'local_blinding' is set to 1 but the memory is never freed.


TIA

Dror
__
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 #690] compilation bug report

[[EMAIL PROTECTED] via RT]

Hello,
compilation of openssl fails on my system. The output of 
make report and make are enclosed below.
Kind regards,
Thomas Wolff


[EMAIL PROTECTED]:~/ein/download/openssl-0.9.7b: make report
Checking compiler...
Running make...
make[1]: Entering directory `/home/thw/ein/download/openssl-0.9.7b'
making all in crypto...
make[2]: Entering directory `/home/thw/ein/download/openssl-0.9.7b/crypto'
gcc -I. -I.. -I../include -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 
-fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM  linux -c 
cryptlib.c -o cryptlib.o
gcc: cannot specify -o with -c or -S and multiple compilations
make[2]: *** [cryptlib.o] Error 1
make[2]: Leaving directory `/home/thw/ein/download/openssl-0.9.7b/crypto'
make[1]: *** [sub_all] Error 1
make[1]: Leaving directory `/home/thw/ein/download/openssl-0.9.7b'
Running make test...
make[1]: Entering directory `/home/thw/ein/download/openssl-0.9.7b'
c_rehash: rehashing skipped ('openssl' program not available)
touch rehash.time
testing...
make[2]: Entering directory `/home/thw/ein/download/openssl-0.9.7b/test'
gcc -I.. -I../include  -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer 
-m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM  linux -c bntest.c -o bntest.o
gcc: cannot specify -o with -c or -S and multiple compilations
make[2]: *** [bntest.o] Error 1
make[2]: Leaving directory `/home/thw/ein/download/openssl-0.9.7b/test'
make[1]: *** [tests] Error 2
make[1]: Leaving directory `/home/thw/ein/download/openssl-0.9.7b'

OpenSSL self-test report:

OpenSSL version:  0.9.7b
Last change:  Countermeasure against the Klima-Pokorny-Rosa extension...
Options:   no-krb5
OS (uname):   Linux scotty 2.2.13 #1 Mon Nov 8 15:08:22 CET 1999 i686 unknown
OS (config):  i686-whatever-linux2
Target (default): linux-pentium
Target:   linux-aout
Compiler: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Failure!
[...]

Test report in file testlog

[EMAIL PROTECTED]:~/ein/download/openssl-0.9.7b: make
making all in crypto...
make[1]: Entering directory `/home/thw/ein/download/openssl-0.9.7b/crypto'
( echo "#ifndef MK1MF_BUILD"; \
echo '  /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */'; \
echo '  #define CFLAGS "gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=pentium -Wall 
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM"'; \
echo '  #define PLATFORM "linux-pentium"'; \
echo "  #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \
echo '#endif' ) >buildinf.h
gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -mcpu=pentium -Wall 
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM  linux -c cryptlib.c -o cryptlib.o
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory `/home/thw/ein/download/openssl-0.9.7b/crypto'
make: *** [sub_all] Error 1

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #669] select patches for DOS

[[EMAIL PROTECTED] via RT]

On Sat, 27 Sep 2003, Richard Levitte via RT wrote:

> I applied your changes to 0.9.8-dev and 0.9.7-stable.  Thank you.
> 
> Ticket resolved.
> 
> [EMAIL PROTECTED] - Tue Jul 29 09:10:37 2003]:
> 
> > These are my patches to get "openssl s_client" working on
> > MSDOS / djgpp / Watt-32. 
 
The patch was revised by Gisle on August 19th. I know it was sent to
openssl-dev, but I'm not sure it went to rt. Please use the revised
patch.
  Doug
 

-- 
Doug Kaufman
Internet: [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #709] OpenSSL-0.9.7c on Solaris

[[EMAIL PROTECTED] via RT]

I've tried to create a package for OpenSSL-0.9.7c on Solaris (8 and 9) and have seen a 
potential problem with the man page creation.  It seems that in the man3 section the 
files EVP_MD_CTX_copy and EVP_MD_CTX_copy_ex are created as one file called 
"EVP_MD_CTX_copy EVP_MD_CTX_copy_ex.3".  I looked into the file and noticed that line 
136 reads as follows:
"EVP_MD_CTX_copy_ex EVP_MD_CTX_copy, EVP_MD_type, EVP_MD_pkey_type,"

Shouldn't there be a comma between EVP_MD_CTX_copy_ex and EVP_MD_CTX_copy?  Is this a 
Solaris related problem or a typo in the pod files?

Thanks,

Jason Czech
SCSU

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #712] OpenSSL 0.9.7c EVP_DigestInit.pod missing a comma in line 7

[[EMAIL PROTECTED] via RT]

Line 7 of EVP_DigestInit.pod is the file that needs the comma between
EVP_MD_CTX_copy_ex and EVP_MD_CTX_copy

 

I added it to my own source but you should add it overall.  Sorry for
the double posting, but not sure if anyone else has brought this to your
attention.

 

Jason Czech

SCSU

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #709] AutoReply: OpenSSL-0.9.7c on Solaris

[[EMAIL PROTECTED] via RT]

Also, line 8 of ui.pod needs a comma on the end, I keep finding them.
Also, this is kind of cosmetic and makes it easier, but in des_modes.pod
could you change the spaces in the name (line 5) to underscores?  Spaces
break the package making process on Solaris quite quickly.

Thanks!

Jason Czech

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> cottbus.de] On Behalf Of OpenSSL-Bugs
> Sent: Wednesday, October 01, 2003 1:54 AM
> To: [EMAIL PROTECTED]
> Subject: [openssl.org #709] AutoReply: OpenSSL-0.9.7c on Solaris
> 
> 
>Greetings,
> This message has been automatically generated in response to
the
> creation of a trouble ticket regarding:
>   "OpenSSL-0.9.7c on Solaris",
> a summary of which appears below.
> 
> There is no need to reply to this message right now.  Your ticket has
been
> assigned an ID of [openssl.org #709].
> 
> Please include the string:
> 
>  [openssl.org #709]
> 
> in the subject line of all future correspondence about this issue. To
do
> so,
> you may reply to this message.
> 
> Thank you,
> 
> 
>

-
> I've tried to create a package for OpenSSL-0.9.7c on Solaris (8 and 9)
and
> have seen a potential problem with the man page creation.  It seems
that
> in the man3 section the files EVP_MD_CTX_copy and EVP_MD_CTX_copy_ex
are
> created as one file called "EVP_MD_CTX_copy EVP_MD_CTX_copy_ex.3".  I
> looked into the file and noticed that line 136 reads as follows:
> "EVP_MD_CTX_copy_ex EVP_MD_CTX_copy, EVP_MD_type, EVP_MD_pkey_type,"
> 
> Shouldn't there be a comma between EVP_MD_CTX_copy_ex and
EVP_MD_CTX_copy?
> Is this a Solaris related problem or a typo in the pod files?
> 
> Thanks,
> 
> Jason Czech
> SCSU
> 


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #709] AutoReply: OpenSSL-0.9.7c on Solaris

[[EMAIL PROTECTED] via RT]

That's an OK solution, but what are the feelings towards those commas?
Are those left out on purpose or were they typos?

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> cottbus.de] On Behalf Of Richard Levitte - VMS Whacker via RT
> Sent: Wednesday, October 01, 2003 10:56 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [openssl.org #709] AutoReply: OpenSSL-0.9.7c on Solaris
> 
> 
> In message <[EMAIL PROTECTED]> on Wed,  1 Oct
2003
> 16:36:20 +0200 (METDST), "[EMAIL PROTECTED] via RT"
<[EMAIL PROTECTED]>
> said:
> 
> rt> Also, line 8 of ui.pod needs a comma on the end, I keep finding
them.
> rt> Also, this is kind of cosmetic and makes it easier, but in
> des_modes.pod
> rt> could you change the spaces in the name (line 5) to underscores?
> Spaces
> rt> break the package making process on Solaris quite quickly.
> 
> I think I'd rather detect if a name has spaces in it, and then simply
> skip over it.  There will still be the file des_modes.7, which is what
> all the other pages are refering to anyway.
> 
> --
> 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.org #719] BUG: Incorrect child exit status handling in Configure 0.9.7c

[[EMAIL PROTECTED] via RT]

Perl script Configure does not properly extract child exit value from $?
on line 1485. Proper parsing is to use the upper 8 bits of the 16-bit word
in $?. See the attached SourceForge patch 816713 for a proposed fix.

P.S. An unpleasant side-effect of this bug is that certain 
OS's might not detect that Configure has exited with an 
error.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #721] BUG: Short passwords not allowed 0.9.7c

[[EMAIL PROTECTED] via RT]

OpenSSL enforces the minimum password length to be 4 characters. However,
this enforcement should be only applied during encryption, not decryption.
The current version does not allow decrypting when the prompted-for
password is too short:

$ openssl rsa -check -in rsa.key -noout
Enter pass phrase for rsa.key:
1312:error:28069065:lib(40):UI_set_result:result too
small:crypto/ui/ui_lib.c:847:You must type in 4 to 511 characters
Enter pass phrase for rsa.key:

Specifying the password on the command line works as expected:

$ openssl rsa -check -in rsa.key -passin pass:foo -noout
RSA key ok
$

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #720] BUG: Inconsistent MinGW identification in Configure 0.9.7c

[[EMAIL PROTECTED] via RT]

Perl script Configure is not consistent in identifying target MinGW.
Sometimes it uses "mingw", sometimes "Mingw32". This causes a check on
line 920 to fail even when it should not.  See the attached SourceForge
patch 816736 for a proposed fix.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #722] FIX: DLL relocation in ms/mingw32.bat 0.9.7c

[[EMAIL PROTECTED] via RT]

Relevance: 0.9.7c, MinGW

Calling tool dllwrap in ms/mingw32.bat currently creates DLLs out of
static libraries in the current directory, instead of where they belong
("./out"). The attached SourceForge patch 816957 for ms/mingw32.bat fixes
the issue by moving the DLLs into the right place afterwards.


--- ms\mingw32.bat  2003-10-02 21:56:20.0 -0600
+++ ms\mingw32.bat.new  2003-10-02 22:07:32.0 -0600
@@ -81,8 +81,10 @@
 echo Generating the DLLs and input libraries
 dllwrap --dllname libeay32.dll --output-lib out/libeay32.a --def ms/libeay32.def 
out/libcrypto.a -lwsock32 -lgdi32
 if errorlevel 1 goto end
+move /y libeay32.dll out
 dllwrap --dllname libssl32.dll --output-lib out/libssl32.a --def ms/ssleay32.def 
out/libssl.a out/libeay32.a
 if errorlevel 1 goto end
+move /y libssl32.dll out
 
 echo Done compiling OpenSSL
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #724] RQ: Library name unification for Win32 possible?

[[EMAIL PROTECTED] via RT]

Feature Request: Would it be please possible in some future OpenSSL
release to use the same name for libssl when converted into a DLL
regardless of the used compiler? MSVC currently calls it "ssleay32.dll"
while MinGW uses "libssl32.dll".

Thank you for consideration.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #741] Bug report

[[EMAIL PROTECTED] via RT]

Hi

I would like to report what I believe is a bug in the openssl code.
Please forgive me if I do not follow any standard procedures you have
for reporting bugs.

The openssl version this bug relates to is openssl 0.9.7c, but I believe
it also applies to earlier versions.

The bug lies in the code where calls to X509_STORE_add_cert(), and
X509_STORE_add_crl() are made.
e.g. (from x509\by_file.c)

i=X509_STORE_add_cert(ctx->store_ctx,x);
if (!i) goto err;
count++;
X509_free(x);
x=NULL;

note that X509_free() is called if the call to X509_STORE_add_cert is
successful. I believe this is wrong because if successful, the pointer
to the certificate (x) is now 'owned' by the store.
It is correct to free 'x' if the call is unsuccessful as the caller will
still 'own' x, and the certificate won't be in the store.

if we look at X509_STORE_add_cert...

int X509_STORE_add_cert(X509_STORE *ctx, X509 *x)
{
X509_OBJECT *obj;
int ret=1;

if (x == NULL) return 0;
obj=(X509_OBJECT *)OPENSSL_malloc(sizeof(X509_OBJECT));
if (obj == NULL)
{

X509err(X509_F_X509_STORE_ADD_CERT,ERR_R_MALLOC_FAILURE);
return 0;
}
obj->type=X509_LU_X509;
obj->data.x509=x;
you can see that x is used by the store.

The same sort of problem exists with calls to X509_STORE_add_crl()

I would suggest that all calls to those two functions are checked to
ensure that 'x' is not freed after a successful call.

I think that most if not all calls are made in x509\by_file.c.

I know that the openbsd project also calls X509_STORE_add_cert, but I am
not sure if that has anything to do with you. (src\isakmpd\x509.c)
In that file, they need to free the certificate is the call is not
successful, which is probably not all that likely to occur.

Chris


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #743] Bug in AES_cbc_encrypt

[[EMAIL PROTECTED] via RT]

The function AES_cbc_encrypt has a bug when its input and output 
parameters are the same which causes it to incorrectly update the IV.
All other OpenSSL ..._cbc_encrypt functions happily accept 
input==output, I don't see a valid reason why AES would be the 
exception.  The attached patch fixes the problem, but a revisitation of 
the AES CBC functions may be in order in order to optimise (I'm sure 
it's got to be possible to encrypt/decrypt without memcpying so much)

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #749] bug in engine hw_cswift.c(cswift_rand_bytes) && patch

[[EMAIL PROTECTED] via RT]

OpenSSL version 0.9.7c
OpSys: SunOS boost 5.8 Generic_108528-15 sun4u sparc SUNW,UltraAX-12

Hi.

The hw_cswift.c(cswift_rand_bytes) has a "note" in a comment stating that 
CryptoSwift
accelerator card can only deal with requests that are even 32 bit (4 byte) 
multiplies;
however the OpenSSL code does nothing to enforce this limitation.

Also, I noticed that the shortest rand request that cswift accelerator accepts
is 8 bytes (64 bits) (i.e. my setup fails with a 4 byte request).

The problem is triggered also internally in OpenSSL e.g. when RAND_bytes()
gets called from RSA_padding_add_PKCS1_type_2() when using 128 byte key
resulting in a RAND_bytes() call with a length of 117 bytes.

This is easy to fix in cswift_rand_bytes, enclosed please find one possible 
way to do it.
The fix verifies the arguments and if the length would not be accepted by the 
cswift, it allocates
a temporary buffer of correct size and then copies the cswift generated rand 
bytes
to caller supplied original buffer from the temp buffer and frees the temp 
buffer.

Thanks,
Juki
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #774] problem installing openssl-0.9.4

[[EMAIL PROTECTED] via RT]

Hi, 

when i run ./config i get:

Operating system: sun4u-sun-solaris2
./config: test: unknown operator (GCC)  

then on running make i get:

making all in crypto...
( echo "#ifndef MK1MF_BUILD"; \
echo "  /* auto-generated by crypto/Makefile.ssl for crypto/cversion.c */"; \
echo "  #define CFLAGS \"cc -DTHREADS -D_REENTRANT -xtarget=ultra -
xarch=v8plus
-xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM\""; 
\
echo "  #define PLATFORM \"solaris-sparcv9-cc\""; \
echo "  #define DATE \"`date`\""; \
echo "#endif" ) >buildinf.h
cc -I. -I../include -DTHREADS -D_REENTRANT -xtarget=ultra -xarch=v8plus -xO5 -
xs
trconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM  -c  
cryptlib.
c
sh: cc: not found
*** Error code 1
make: Fatal error: Command failed for target `cryptlib.o'
Current working directory /stl/blyth/openssl-0.9.4/crypto
*** Error code 1
make: Fatal error: Command failed for target `all'

Please can you help

Regards

[EMAIL PROTECTED]
--
Swallow Technology Limited
[EMAIL PROTECTED]
Tel: +44 (0)20 7350 5000
Fax: +44 (0)20 7350 5010

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]