[16985] in Kerberos_V5_Development
Re: : Why are we using libverto again
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Jul 7 11:46:44 2011
From: Sam Hartman <hartmans@mit.edu>
To: Simo Sorce <simo@redhat.com>
Date: Thu, 07 Jul 2011 11:46:36 -0400
In-Reply-To: <1310052377.8182.18.camel@willson.li.ssimo.org> (Simo Sorce's
message of "Thu, 07 Jul 2011 11:26:17 -0400")
Message-ID: <tslhb6y3xgj.fsf@mit.edu>
MIME-Version: 1.0
Cc: Nico Williams <nico@cryptonector.com>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>>>>> "Simo" == Simo Sorce <simo@redhat.com> writes:
Simo> On Thu, 2011-07-07 at 10:44 -0400, Sam Hartman wrote:
>>
>> So, as far as I can tell dladdr is a glibc extension. So, we cannot
>> even guarantee it's present on Unix platforms.
>>
>> I'm very concerned about the portability impact of this many shared
>> library tricks. Without win32 portability we can never use this in
>> libkrb5. So, it's only valuable for the KDC.
Simo> Many ?
Simo> dladdr() is the only trick I am aware of.
dlopen the application
dladdr
Looking for what event libraries are already linked in.
>> Now, for the KDC today, we could just use a specific event library and
>> gain significant complexity savings.
Simo> libverto is not complex at all and saves you from forcing a specific
Simo> dependency on a system given it seem different OSs are standardizinf on
Simo> different event libraries for now.
I think it is reasonable and desirable for the KDC to pick a particular
event library when running in stand alone mode.
>> I'm quite concerned that the complexity of libverto is too great to
>> depend on just for simplifying a future libkdc.
Simo> Please take a look at the code.
I'll do that, but the bugs and type of bugs to date already exceepd my
estimate of complexity to value.
>> This is particulary true because several of the uses of libkdc such as
>> pku2u or some of the eap preauth cases would strongly benefit from
>> porting to Windows.
Simo> Windows was not stated as a necessary dependency when the project was
Simo> started. If it is now I am sure we can add it on the roadmap. The only
Simo> issue is that I know of no event libraries available in Windows at all
Simo> unless you count stuff that compiles on cygwyn/mingw which you said is
Simo> not ok.
libevent.
mingw doesn't bother me so much if you can produce a dll and import
library and have no dependencies on msys.
However, libevent seems to have msvc solutions included in the source so
I suspect it does not require mingw.
>> I think we need to take a step back and carefully consider whether this
>> direction makes sense.
Simo> It definitely does, the other option is to make the KDC threaded, and it
Simo> looks like that direction is even less desirable atm.
>
My preferred solution is to pick a specific event library for the KDC.
The libkdc implications are not ideal, but I think this option needs to
at least be given significantly more consideration than it has been to
date.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
