Subject:                Re: [openssl.org #277] COMP_zlib Problem
From:                   "Lutz Jaenicke via RT" <[EMAIL PROTECTED]>
To:                     [EMAIL PROTECTED]
Copies to:              [EMAIL PROTECTED]
Date sent:              Tue, 10 Sep 2002 10:15:19 +0200 (METDST)
Send reply to:          [EMAIL PROTECTED]

Lutz

There is still a problem in kssl.c which prevents the OpenSSL-
0.9.7beta3 server code from working when Kerberos 5 authentcation is 
requested.  I sent the code necessary to fix this many months ago (I 
worked with Dr. Henson on the problem).  The code I sent must have 
been lost, thown away or discarded.  It consisted of a short patch to 
kssl.c in the ssl directory.

What is the correct procedure to follow to get this fixed?  I really 
don't care if my patch is used or someone elses; I just would like to 
see this stuff work as distributed.

Ken


  
On Mon, Sep 09, 2002 at 10:43:51AM -0500, Kenneth R. Robinette wrote:
> If one calls COMP_METHOD *comp = COMP_zlib(), the first time this 
> call is made, a valid COMP_METHOD is returned, and the comp->type is 
> set correctly.  However, if you make the call a second time, a valid 
> COMP_METHOD is returned, however the comp->type is set to 0.

That does not make sense to me.
COMP_zlib in any case of success returns a pointer to the zlib_method
structure, which is a static entry in crypto/comp/c_zlib.c. There the 
"type"
member is set to NID_zlib_compression. Thus the only reason why type
is "0" would be that "zlib_method" would be overwritten (destroyed).

However: If COMP_zlib() fails, a pointer to the zlib_method_nozlib 
structure
is returned. This is also a valid pointer (not a NULL pointer), but
it does not provide any compression at all. Its type is "NID_undef",
which in turn is 0.
>From the code, it seems, that this would be the result with 
ZLIB_SHARED
and COMP_zlib() being called more than once. zlib_loaded is true 
(succussfully
loaded the first time) and then meth is not set to zlib_method 
again...

I am not sure about the intended behaviour, but it probably is not
intended this way (read this: it seems to be a bug to me :-).
I have therefore bounced this issued into the request tracker.

Best regards,
        Lutz
-- 
Lutz Jaenicke                             [EMAIL PROTECTED]
Cottbus.DE
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                       openssl-
[EMAIL PROTECTED]
Automated List Manager                           
[EMAIL PROTECTED]
_
Support
InterSoft International, Inc.
Voice: 888-823-1541, International 281-398-7060
Fax: 888-823-1542, International 281-560-9170
[EMAIL PROTECTED]
http://www.securenetterm.com


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

Reply via email to