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 #640] bug: Makefile.ssl for do_srv3-shared and do_svr5-shared buggy

[Richard Levitte via RT]

I haven't heard anything further on this, or at least, I can't see it in
this database...

[levitte - Thu Jul  3 23:41:28 2003]:

> Since all lines returned by find will contain at least one slash, the
> obvious solution is to add a slash in the argument to grep, thus doing
> "grep /$$obj allobjs" instead of "grep $$obj allobjs".  That's the
> change I'm going to commit.
> 
> Thanks for the report.   Please test tomorrows snapshot.
> 
> [EMAIL PROTECTED] - Fri Jun  6 14:32:15 2003]:
> 
> > 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
> >
> 


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

[openssl.org #657] v3_prn.c cosmetical bug/patch

[Richard Levitte via RT]

I've applied the changes 1, but not for 2, which I didn't quite understand.

[EMAIL PROTECTED] - Thu Jul 10 08:44:40 2003]:

> Hi
> 
> I think there are 2 cosmetical bugs in v3_prn.c.
> 
> 1.) The indentation of the v3 extension values is fix '12' instead of
>  'indent + 4'
> 
> 2.) After the last multi-line extension value the '\n' should not
>  be printed
> 
> See attached a patch.
> 
> best regards
> 
> Matthias


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

[openssl.org #661] bug in x509_vfy.c

[Richard Levitte via RT]

I'll look at it in a few days.  Right now, I feel unsure about all the
implications of such a change.

[EMAIL PROTECTED] - Fri Jul 11 21:14:39 2003]:

> 
> OPENSSL VERSION: 0.9.6j
> PLATFORM: all
> SEVERITY: minor
> 
> In x509_vfy.c:X509_verify_cert, there are some cases where an error
> occurs and ctx->error is set, but the error isn't added to the error
> stack (with X509err).  The only cases where this happens are when the
> verify callback is called (so that it can potentially handle or ignore
> the error), but if the callback fails (returns 0), the error still isn't
> added to the openssl error stack.  It would be nice to get the error
> info (file, line number, etc.) from that error, by calling
> X509err(X509_F_ERR_VERIFY_CERT, ctx->error) if the callback fails.
> 
> 
> 


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

[openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

[Richard Levitte via RT]

OK, what's the status on this ticket?

[bodo - Tue Feb  4 17:30:23 2003]:

> Arne Ansper <[EMAIL PROTECTED]>:
> 
> >> Like I say, they should only do this if there was an error reported,
> surely?
> 
> > No. Take a look at the SSL_CTX_use_certificate_chain_file:
> >
> > ret=SSL_CTX_use_certificate(ctx,x);
> > if (ERR_peek_error() != 0)
> > ret = 0;  /* Key/certificate mismatch doesn't imply ret==0
... */
> 
> Actually I think this is a bug in SSL_CTX_use_certificate() -- if it
> intentionally ignores an error returned by X509_check_private_key(),
> it should call ERR_clear_error().
> 
> The reason why I did not fix this when I looked at this some time ago
> is some rather weird code in ssl_set_cert(), the function used by
> SSL_CTX_use_certificate() from which X509_check_private_key() is
> called.  (If you look at ssl_set_cert(), you'll see that it switches
> from SSL_PKEY_DH_RSA to SSKL_PKEY_DH_DSA and the other way around,
> which does not appear to make much sense.)  Investigating this has
> been on my "to do" list for a while.  Once this has been resolved,
> the lines
> 
>  if (ERR_peek_error() != 0)
> ret = 0;  /* Key/certificate mismatch doesn't imply ret==0 ... */
> 
> can be removed from SSL_CTX_use_certificate_chain_file().


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

[openssl.org #664] Bug in md5 calculation

[Richard Levitte via RT]

I did as you suggested and changed jge to jae in the branches 0.9.8-dev,
0.9.7-stable and 0.9.6-stable.  Please test tomorrow's snapshots.

Thanks for your contribution.  Ticket resolved.

[EMAIL PROTECTED] - Tue Jul 22 10:52:32 2003]:

> When calling the MD5 function on very large data sets (around 2GB) in
> memory or from a memory map, the computed MD5 sum is false and even
> worth, can cause the program to crash with a seg-fault. By tracking
> down
> the calculation of the sum, I found out that this behaviour occurs
> when
> the data pointer crosses the address 0X8000L in the MD5_Update()
> function, thus wrapping around from a positive to negative integer.
> The
> reason for this error lies in the comparison of two signed numbers
> rather than two unsigned numbers in the assembly code found in
> crypto/md5/asm/md5-586.pl at line 296. Instead of a "jge" (greater
> equal) instruction, there should be a "jae" (above equal) instruction
> for evaluating an unsigned compare.
> 
> An even better fix, IMHO, would be to omit the 64 bytes subtraction
> from
> the target address register right at the begining of the function call
> and then just compare the pointers for equality (jne).
> 
> In order to compile, the "jae" instruction must also be added
> somewhere
> in the crypto/perlasm/x86unix.pl and x86ms.pl perl scripts.
> 
> 
> OpenSSL self-test report:
> 
> OpenSSL version:  0.9.7c-dev
> Last change:  In ssl3_get_client_hello() (ssl/s3_srvr.c), tolerate
> ad...
> Options:   no-krb5
> OS (uname):   Linux mx040 2.4.4-4GB #1 Wed May 16 00:37:55 GMT
> 2001
> i686 unknown
> OS (config):  i686-whatever-linux2
> Target (default): linux-pentium
> Target:   linux-pentium
> Compiler: Configured with:
> Thread model: posix
> gcc version 3.2.2
> 
> Eric


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

[openssl.org #669] select patches for DOS

[Richard Levitte via RT]

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 assumtion that DOS in general can do select() on stdin/stdout 
> is wrong (allthough djgpp has some support for it, it's slow and clunky). 
> My patch uses kbhit() as Win32/WinCE does.
>  
> One other patch: I had to prevent setting stdin/stdout in O_BINARY
> mode in crypto/bio/bss_file.c. Because it will disable breaking out of a
> stuck programs (^C/^Break stops working in binary mode). 
> 
> After these patches I'm able to do:
> echo GET /index.html | openssl.exe s_client -connect www.fortify.net:443
> 
> and it gives me get index.html okay. So I guess it works!!
> 
> Patch against latest 0.9.8 beta snapshot attached.
> 
> Gisle V.
> 
> # rm /bin/laden 
> /bin/laden: Not found 

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

[openssl.org #670] -fPIC flag missing for asm/des_enc-sparc.

[Richard Levitte via RT]

Uhmm, which OpenSSL version are you talking about?  I can't find
des_enc-sparc.S anywhere in my copy of the 0.9.7 branch...

[EMAIL PROTECTED] - Tue Jul 29 17:06:13 2003]:

> 
> it seems that in the current snapshots the shared
> option for solaris does not work correctly.
> 
> Compilation in crypto/des of
> 
>gcc  -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S
> 
> should probably be
> 
>gcc -fPIC -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S
> 
> in order not to provoke a linker error.
> 
> 
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]


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

[openssl.org #675] Error 140890B2:SSL

[Richard Levitte via RT]

Here's how you find out what the error code means:

  openssl errstr 140890B2

I got the following:

  error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate
returned

This means the server or the JServlet has been configured to require the
client to submit a client certificate, but doesn't get one.

Does that help?

[guest - Thu Aug 14 16:49:19 2003]:

> Hi,
> 
> Have a problem with the error in the subject field.
> We are running a JServlet on an Apache server and getting the above 
> error. It has to do with a problem with a security certificate and it's 
> hand shake with the client.
> 
> Any help would be appeciated.

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

[openssl.org #676] Small OpenSSL

[Richard Levitte via RT]

I've a small comment to contribute first, then I'll go through the rest
of your contribution.

[EMAIL PROTECTED] - Thu Aug 14 17:33:20 2003]:

>   - Do not suppress TLS when Diffie-Hellman is excluded.

RFC2246 says the following:

9. Mandatory Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

That implies that OpenSSL MUST support DH, DSA, 3DES and SHA.

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

[openssl.org #678] Crash in lhash code in openssl 0.9.7a

[Richard Levitte via RT]

OK, just implemented and committed.  Please try tomorrow's snapshot.

I'm not releasing this ticket yet, as I suspect there may be discussions
about this change...

[levitte - Sat Sep 27 22:19:53 2003]:

> It seems to me that adding a reference counter is a bit better.  This
> means that we need to have one extra function (and callback) to
>release
> a pointer (and thereby decreas the reference count).
> 
> I'm experimenting with that approach as I write, and I'm going to
> release soon unless someone sees a problem with that approach.
> 
> Your alternative will unfortunately mean that we'll get a large number
> of reports telling us about the memory leak reported by valgrind and
> whatnot.  I'd prefer to stay away from there if possible.
> 
> [EMAIL PROTECTED] - Tue Aug 19 10:34:05 2003]:
> 
> > I get a crash in the lhash code in Openssl 0.9.7a. The troublesome
>case
> > is when it is called from err/err.c in a multithreaded environment.
> >
> > The root cause *may* be that the hash is destroyed by
> > int_thread_del_item while (say) int_thread_get has a copy of the
> > pointer. The locking does not seem to cover the gap between loading
>the
> > pointer (int_thread_hash) and then using it. Rather the lock is
>taken
> > out, the pointer loaded, the lock released. The lock is then re-
>acquired
> > and then the pointer is used. This seems wrong.
> >
> > My simple-minded proposal to fix the problem is to delete the code
>in
> > int_thread_del_item that deletes the hash when it becomes empty.
>Yes,
> > this will result in some memory being reserved and not freed..
>I
> > also suspect that the same problem could arise with int_error_hash
>--
> > that pointer is returned by int_err_get() when no lock is being
>held.
> >
> > Advice?
> >
> > Philip
> 


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

[openssl.org #678] Crash in lhash code in openssl 0.9.7a

[Richard Levitte via RT]

It seems to me that adding a reference counter is a bit better.  This
means that we need to have one extra function (and callback) to release
a pointer (and thereby decreas the reference count).

I'm experimenting with that approach as I write, and I'm going to
release soon unless someone sees a problem with that approach.

Your alternative will unfortunately mean that we'll get a large number
of reports telling us about the memory leak reported by valgrind and
whatnot.  I'd prefer to stay away from there if possible.

[EMAIL PROTECTED] - Tue Aug 19 10:34:05 2003]:

> I get a crash in the lhash code in Openssl 0.9.7a. The troublesome case 
> is when it is called from err/err.c in a multithreaded environment.
> 
> The root cause *may* be that the hash is destroyed by 
> int_thread_del_item while (say) int_thread_get has a copy of the 
> pointer. The locking does not seem to cover the gap between loading the 
> pointer (int_thread_hash) and then using it. Rather the lock is taken 
> out, the pointer loaded, the lock released. The lock is then re-acquired 
> and then the pointer is used. This seems wrong.
> 
> My simple-minded proposal to fix the problem is to delete the code in 
> int_thread_del_item that deletes the hash when it becomes empty. Yes, 
> this will result in some memory being reserved and not freed..   I 
> also suspect that the same problem could arise with int_error_hash -- 
> that pointer is returned by int_err_get() when no lock is being held.
> 
> Advice?
> 
> Philip


-- 
Richard Levitte
[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()

[Richard Levitte via RT]

Same argument as for ticket 680: no harm done, and makes this function
consistent with the rest of them.  Applied.

Thanks.  Ticket resolved.

[EMAIL PROTECTED] - Thu Aug 21 07:38:16 2003]:

> 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]


-- 
Richard Levitte
[EMAIL PROTECTED]
__
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()

[Richard Levitte via RT]

I see no harm in that patch, and it makes
ssl3_send_certificate_request() consistent with all the other similar
functions, so I applied it.

Thanks.  Ticket resolved.  Please try the next snapshot.

[EMAIL PROTECTED] - Thu Aug 21 07:38:18 2003]:

> 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]


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

[openssl.org #700] PKCS7 Des key parity

[Robin Ehrlich via RT]

I have an application using the OpenSSL S/MIME interface. When I generate an 
encryptred message using DES, the DES key generated does not have odd parity.  The key 
is generated in pk7_doit.c:PKCS7_dataInit by calling RAND_bytes().

In testing interoperability with the NIST S/MIME test center, the message is rejected. 
I know that odd parity is not a DES requirement, but DES keys should have odd parity.

Dr Stephen N. Henson suggested the following solution and that this problem be 
reported as a bug to be fixed in an upcoming release:

Probably the best way is to add a flag to EVP_CIPHER which indicates that the
key needs odd parity and then check the flag when a random key is generated
and fix it up appropriately.


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

[openssl.org #685] bio.h + intel Compiler request

[Richard Levitte via RT]

I did it better: I just removed the extra arguments from all the
BIO_printfs in apps/pkcs8.c that had it.  Please try tomorrow's snapshot.

Thank you.  Ticket resolved.

[EMAIL PROTECTED] - Wed Sep 10 08:08:57 2003]:

> Hi,
> can you add
> 
> #ifdef __INTEL_COMPILER
> #pragma warning (disable:268)
> #endif
> 
> to \crypto\bio\bio.h ?
> 
> All description see below :)
> 
> Evgeny.
> 
> 
> 
>   BIO_printf and compiler error #268
>Issue Number 203032   Issue Status Answered
>Originator Evgeny Sabelsky   Submit Date 8/19/2003
>Company Medweb Inc.   Last Update 9/2/2003
>Intel Contact Closed Date 9/2/2003
>Product Type Development Environment (tools,SDV,EAP)   Product
Status
> Released
>Product Name Intel(R) C++ Compiler for Windows*
>   Additional product info --Product Info/Self Help   File
Downloads
> (19)
>   Question
>   .\apps\pkcs8.c(326): error #268: the format string ends before this
> argument
>   BIO_printf(bio_err, "Error converting key\n", outfile);
> 
>   Why ? BIO_printf isn't standard function, so, icl shouldn't check
> arguments
> 
>   Issue Communication Reply to Issue
> 
>   Feedback from Evgeny Sabelsky: 8/27/2003 11:59:11 PM
>   Yes :) but i saw #error instead of warning in 7.0.??? version, i
have
> updated to latest 7.1.019 and it seems like works good. Now i see #warning
> message.
> 
>   Thanks.
> 
>   Updated by Intel: 8/27/2003 1:43:29 PM
> 
>   Hi Evgeny,
> 
>   Upon our developer review, this warning message is Okay. You could
> turn off the warning if you don't like to see the warning message by
typing:
>   #pragma warning (disable:268)
> 
>   Regards,
>   Ying Ning
>   Intel Customer Support
> 
> 
> 
> 
> 
>   Updated by Intel: 8/21/2003 11:53:33 AM
> 
>   Hi Evgeny,
> 
>   I reproduced your issue and entered it in our problem tracking
system.
> I will let you know when I have an update on this issue.
> 
>   Regards,
>   Ying Ning
>   Intel Customer Support
> 
> 
>   Feedback from Evgeny Sabelsky: 8/20/2003 2:07:50 AM
>   Here is the small example:
> 
>   #include 
>   #include 
>   #include 
> 
>   int BIO_printf (const char *format, ...)
>{
>va_list args;
>int ret;
> 
>va_start(args, format);
> 
>ret = 0;
> 
>va_end(args);
>return(ret);
>}
> 
>   void main(void)
>   {
>   BIO_printf("%s%s\n", "1", "2", "some useful string");
>   }
> 
>   Updated by Intel: 8/19/2003 5:06:23 PM
>   Evgeny,
> 
>   Does the usage of BIO_printf match the prototype you have
defined for
> this routine? Is it possible to send a small test case that reproduces
this
> issue? I can then ask the developers for more details on why this error
> message is being displayed.
> 
>   Regards,
> 
>   Elizabeth S.
>   Intel Customer Support
>   Updated by Intel: 8/19/2003 8:53:30 AM
> 
>   Evgeny,
> 
>   I received your issue and I am investigating it. I will send you an
> update soon.
> 
>   Regards,
> 
>   Elizabeth S.
>   Intel Customer Support
> 
>   For on-line assistance:
> http://support.intel.com/support/performancetools
>   For user forums: http://intel.com/ids/community
>   For general support information:
> http://intel.com/software/products/support/index.htm
> 
> 
> 
> 
> 
> 


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

[openssl.org #688] openssl+QNX6.2.1 - HELP PLEASE

[Richard Levitte via RT]

OK, we need to know a few details to enable that:

- How does on tell the cc that it should produce position independent
code (PIC)?
- How does one build a shared library, preferably from a static library?
- Does QNX use dlopen() and friends to load shared libraries, or some
other mechanism?  What's the name of the library containing those functions?

That should pretty much cover what we need to know...

[EMAIL PROTECTED] - Tue Sep 16 12:57:48 2003]:

> hello rt.
> 
>  Hello - could you please help me - i have troubles compiling
>  openssl for qnx 6.2.1 (Neutrino) as shared (.so) libraries -
>  ./config shared says it doesn't yet support such a configuration
> 
>  as I had found in mailing lists - you provided group with
>  *.tar.gz to fix configuration...
> 
>  if possible - send it to me
>  any help will be appreciated...


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

[openssl.org #692] off-by-one bugs

[Richard Levitte via RT]

This has already been corrected, please check a recent snapshot of OpenSSL.

Thanks still.

Ticket resolved.

[EMAIL PROTECTED] - Fri Sep 19 21:06:59 2003]:

> (Excuse the filenames, patch generated from OpenBSD -current sources.)
> 
> Index: lib/libssl/src/apps/openssl.c
> ===
> RCS file: /cvs/src/lib/libssl/src/apps/openssl.c,v
> retrieving revision 1.8
> diff -u -r1.8 openssl.c
> --- lib/libssl/src/apps/openssl.c 12 May 2003 02:18:35 -  1.8
> +++ lib/libssl/src/apps/openssl.c 19 Sep 2003 14:38:36 -
> @@ -163,7 +163,7 @@
>   goto err;
>   }
> 
> - if (type < 0 || type > CRYPTO_NUM_LOCKS)
> + if (type < 0 || type >= CRYPTO_NUM_LOCKS)
>   {
>   errstr = "type out of bounds";
>   goto err;
> Index: lib/libssl/src/ssl/ssltest.c
> ===
> RCS file: /cvs/src/lib/libssl/src/ssl/ssltest.c,v
> retrieving revision 1.9
> diff -u -r1.9 ssltest.c
> --- lib/libssl/src/ssl/ssltest.c  12 May 2003 02:18:40 -  1.9
> +++ lib/libssl/src/ssl/ssltest.c  19 Sep 2003 14:38:37 -
> @@ -291,7 +291,7 @@
>   goto err;
>   }
> 
> - if (type < 0 || type > CRYPTO_NUM_LOCKS)
> + if (type < 0 || type >= CRYPTO_NUM_LOCKS)
>   {
>   errstr = "type out of bounds";
>   goto err;
> 
> ---
> Aaron Campbell ([EMAIL PROTECTED])
> http://www.monkey.org/~aaron
> 


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

[openssl.org #693] [PATCH] Ensure OpenSSL stores Kerberos principal's instance

[Richard Levitte via RT]

I just applied your patch in the 0.9.7 and the 0.9.8-dev branches. 
Please test tomorrow's snapshot.

Thanks for your contribution.  Ticket resolved.

[EMAIL PROTECTED] - Mon Sep 22 21:37:29 2003]:

> 
> 
> 
>   
> 
> 
>     A
>Kerberos
> principal is composed of the name, instance, and realm.
> When using OpenSSL with Kerberos, an OpenSSL server places the
>client's
> principal into ssl->kssl_ctx->client_princ.  However, due
>to a
> bug in
> kssl.c:kssl_ctx_setprinc(), the instance information is never
>copied.
> 
> That is:
> 
> Kerberos principal    Current behavior  
>Patched behavior
> href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]   
>    href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]     
>href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
>
href="mailto:foo/[EMAIL PROTECTED]">foo/[EMAIL PROTECTED]   
>href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]   class="moz-txt-link-abbreviated"
>href="mailto:foo/[EMAIL PROTECTED]">foo/[EMAIL PROTECTED]
> 
>     The attached patch updates kssl_ctx_setprinc() in
>kssl.[ch] to
> ensure ssl->kssl_ctx->client_princ reflects the full
>principal.
> 
>     In addition, the patch update
>s_server.c:init_ssl_connection() to
> print the Kerberos principal on connect (just like
> init_ssl_connection() prints any client certificate information).
> 
>     Tested on Solaris [78], HP-UX 11.00, RH7.2 and
>RHAS21 with MIT
> Kerberos 1.2.x
> 
> Thanks-
>  Dan
> 
> 
> diff -ur openssl-0.9.7-stable-SNAP-20030922/apps/s_server.c
> openssl-0.9.7-stable-SNAP-20030922-work/apps/s_server.c
> --- openssl-0.9.7-stable-SNAP-20030922/apps/s_server.c  Thu Jan
>30
> 14:16:30 2003
> +++ openssl-0.9.7-stable-SNAP-20030922-
>work/apps/s_server.c Mon Sep
> 22 14:35:15 2003
> @@ -1264,6 +1264,13 @@
>
   
>TLS1_FLAGS_TLS_PADDING_BUG)
>
   
>BIO_printf(bio_s_out,"Peer has incorrect TLSv1 block
> padding\n");
> 
> +#ifndef OPENSSL_NO_KRB5
> +    if (con->kssl_ctx->client_princ != NULL)
> +    {
> +   
>BIO_printf(bio_s_out,"Kerberos peer principal is %s\n",
> +   
>con->kssl_ctx->client_princ);
> +    }
> +#endif /* OPENSSL_NO_KRB5 */
>     return(1);
>     }
> 
> diff -ur openssl-0.9.7-stable-SNAP-20030922/ssl/kssl.c
> openssl-0.9.7-stable-SNAP-20030922-work/ssl/kssl.c
> --- openssl-0.9.7-stable-SNAP-
>20030922/ssl/kssl.c   Wed Mar 26
> 14:16:38 2003
> +++ openssl-0.9.7-stable-SNAP-20030922-work/ssl/kssl.c  Mon Sep
>22
> 14:34:20 2003
> @@ -1497,7 +1497,8 @@
>
   
>}
>     else if
>(kssl_ctx_setprinc(kssl_ctx, KSSL_CLIENT,
>

>&krb5ticket->enc_part2->client->realm,
>
-   
>krb5ticket->enc_part2->client->data))
>
+   
>krb5ticket->enc_part2->client->data,
>
+   
>krb5ticket->enc_part2->client->length))
>

>{
>
   
>kssl_err_set(kssl_err, SSL_R_KRB5_S_BAD_TICKET,
>

>"kssl_ctx_setprinc() fails.\n");
> @@ -1564,16 +1565,17 @@
>  }
> 
> 
> -/* Given a (krb5_data *) entity (and optional
>realm),
> +/* Given an array of (krb5_data) entity (and
>optional realm),
>  ** set the plain (char *) client_princ
>or service_host member
>  ** of the kssl_ctx struct.
>  */
>  krb5_error_code
>  kssl_ctx_setprinc(KSSL_CTX *kssl_ctx, int which,
> -    krb5_data *realm,
>krb5_data *entity)
> +    krb5_data *realm,
>krb5_data *entity, int nentities)
>  {
>     char   
>**princ;
>     int
>length;
> +   int
>i;
> 
>     if (kssl_ctx == NULL 
>||  entity == NULL)  return KSSL_CTX_ERR;
> 
> @@ -1585,18 +1587,32 @@
>
   
>}
>     if (*princ) 
>free(*princ);
> 
> -   length = entity->length +
>((realm)? realm->length + 2: 1);
> +   /* Add up all the entity-
>>lengths */
> +   length = 0;
> +   for (i=0; i < nentities;
>i++)
>
+  
>{
>
+  
>length += entity[i].length;
>
+  
>}
> +   /* Add in space for the '/'
>character(s) (if any) */
> +   length += nentities-1;
> +   /* Space for the ('@'+realm+NULL
>| NULL) */
> +   length += ((realm)? realm-
>>length + 2: 1);
>     if ((*princ = calloc(1,
>length)) == NULL)
>
   
>return KSSL_CTX_ERR;
>     else
>

>{
>
-  
>strncpy(*princ, entity->data, entity->length);
>
-  
>(*princ)[entity->length]='\0';
>
+  
>for (i = 0; i < nentities; i++)
>
+  
>{
>
+  
>strncat(*princ, entity[i].data,
> entity[i].length);
>
+  
>if (i < nentities-1)
>
+  
>{
>
+  
>strcat (*princ, "/");
>
+ 

[openssl.org #698] documentation bug fix for openssl-0.9.7b

[Richard Levitte via RT]

Applied.  Thanks.  Ticket resolved.

[EMAIL PROTECTED] - Fri Sep 26 08:50:39 2003]:

> INSTALL.W32
> 228c228
> <   $ copy /b inc32\*   c:\openssl\include\openssl
> ---
> >   $ copy /b inc32\openssl\*   c:\openssl\include\openssl
> 
> 


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

[openssl.org #699] Little problem compiling without MD2 support

[via RT]

In test/md2test.c there is a little problem.
The line :
#include 

should be in the else side of #ifdef OPENSSL_NO_MD2, otherwise the make
would stop with and error.

The openSSL version is 0.9.7b 
Here How I fixed ( I know, it's simple, but should work )

--- openssl-0.9.7b/crypto/md2/md2test.c Wed Feb 19 12:22:18 2003
+++ openssl_patched/crypto/md2/md2test.cSat Sep 27 12:10:57 2003
@@ -59,7 +59,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "../e_os.h"
 
@@ -70,6 +69,7 @@
 return(0);
 }
 #else
+#include 
 #include 
 
 #ifdef CHARSET_EBCDIC
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL with KRB5 support, memory leak kssl_ctx_new()

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Fri, 26 Sep 2003 16:27:38 -0400, Andrew Mann <[EMAIL 
PROTECTED]> said:

amann> ssl_lib.c  function SSL_free() does not appear to free this memory.
amann> 
amann>  As a note, the system libraries here are openssl 0.9.7a, but I'm 
amann> looking through the 0.9.7b source and the handling doesn't appear any 
amann> different there.
amann>  In fact, kssl_ctx_free() isn't called from anywhere in ssl/*.c  (it's 
amann> commented out from one location).
amann> 
amann>  Seems like a simple fix:
amann> 
amann> diff -up ssl_lib.c ../ssl-modified/ssl_lib.c
amann> --- ssl_lib.c   2003-01-30 06:00:37.0 -0500
amann> +++ ../ssl-modified/ssl_lib.c   2003-09-26 15:36:14.0 -0400
amann> @@ -473,6 +473,10 @@ void SSL_free(SSL *s)
amann> 
amann>  if (s->method != NULL) s->method->ssl_free(s);
amann> 
amann> +#ifndefOPENSSL_NO_KRB5
amann> +   if (s->kssl_ctx != NULL) kssl_ctx_free(s->kssl_ctx);
amann> +#endif /* OPENSSL_NO_KRB5 */
amann> +
amann>  OPENSSL_free(s);
amann>  }

Thanks for your patch, I just applied it in the 0.9.7 and 0.9.8-dev
branches.

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] VxWorks PowerPC 860 and no-md2

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Fri, 26 Sep 2003 23:16:39 -0700, Bob Bradley <[EMAIL 
PROTECTED]> said:

bob> The attached patch adds Configure script support for VxWorks for PowerPC
bob> 860, fixes a compile problem with VxWorks builds, and fixes build problems
bob> with no-md2.

I've applied your Configure and e_os.h changes on the 0.9.7 branch as
well as in the 0.9.8-dev line.

The no-md2 change were already present in those branches, in a
slightly different form.

Thanks for your contribution.

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]