Re: [Perlgssapi-users] Building perlgssapi against other gssapi impls

[David L. <Dav...@qu...>]

Achim Grolms wrote:
>On Thursday 23 February 2006 05:11, you wrote:
>  
>>Achim Grolms wrote:
>>    
>>>The other point - how can I make the Makefile.PL
>>>to set the DHEIMDAL flag
>>>based on the output of your krb5-config command?
>>>      
>>That is a good question.. I think we will try to make our krb5-config
>>emit '(Heimdal)' as part of the version string.
>>    
>
>Something like "... derived from Heimdal" will work?
>  
Yep. I think the change has already gone in, so in the future we will 
see behaviour something like this:
    $ krb5-config --version
    VAS 3.0.1 (Heimdal 0.7)
>  
>>Or, perhaps you could provide a switch to Makefile.PL that would
>>override the heimdal detection.
>>
>>However, it seems to me that the package currently assumes the
>>extensions are there, falling back to vanilla gssapi *only* if the word
>>Heimdal is detected.. Perhaps the logic should be reversed; i.e. build
>>conservatively, unless the extensions are detected? By extensions I mean
>>the deprecated/non-standard GSSAPI functions like oid_to_str.
>>    
>
>At the moment most of the users I get mail from are using MIT Kerberos.
>The Heimdal support is new in GSSAPI.pm
>I don't want to repair things that are not broken, but you are right,
>if in future the standard behaviour becomes the default I have
>to change that and make a reverse detection.
>
>Does that work for you?
>  
yes it would..

I think it is fair to say that perlgssapi was once a module primarily 
meant for use with mit krb's gssapi C headers (popular) ... but now it 
has heimdal header compatibility..

I would be happy to see it evolve into a module that (on the perl side) 
claims to establish a good perl language binding to the higher-level 
gssapi, and (on the C side) is implemented by bridging only to the RFC's 
C binding and providing implementations of missing C impl to provide the 
perl functionality. eg oid_to_str is not hard to write and could be 
provided in the module so that it is available regardless of heimdal or 
mit underlying implementation...

anyway, that's just my 2c... i'll send patches next time ;)

d

-- 
David Leonard
Vintela Resource Central software engineer
Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com
Phone: (US) +1 801 655 2755 
       (AU) +61 7 3023 5133