directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: Leveraging Kerby Kerberos library in ApacheDS
Date Mon, 03 Aug 2015 14:30:32 GMT
Thanks for the feedback!

>> If we are already nearly ready to go with releasing Kerby anyway, I'm not sure I
see the benefit of releasing the ASN.1 library separately.
I share the same thoughts with Colm on this. If we don’t see any major big concern to cut
the 1.0.0-rc1 release, we can go directly for it. Having the ASN.1 part out would complicate
the relationship between it and the main part in project management. We could consider this
option in future.


From: Colm O hEigeartaigh []
Sent: Friday, July 31, 2015 10:40 PM
To: Apache Directory Developers List
Subject: Re: Leveraging Kerby Kerberos library in ApacheDS

Hi Emmanuel,
If we are releasing the ASN.1 part of Kerby independently, then doesn't this imply that it
should be considered as a separate (sub) project? If we are already nearly ready to go with
releasing Kerby anyway, I'm not sure I see the benefit of releasing the ASN.1 library separately.
Just my 2c, I'll defer to the majority opinion on this.

On Fri, Jul 31, 2015 at 9:27 AM, Emmanuel Lécharny <<>>
Le 31/07/15 09:36, Zheng, Kai a écrit :
>> we can start by releasing teh ASN.1 part of Kerby, and use it in ApacheDS
> I thought it may depend. If we still have a long way to go for the cut of the first release,
then better to release the ASN.1 part first for the use; but if we could get it done not too
late, then ...

The rational here is that we need this ASN.1 lib for ApacheDS,
regardless of Kerby.

Let me explain what I have in mind here :
- from day one, the idea was for Kerby to be independant from ApacheDS,
as much as possible, but still making ut possible to bundle the two guys
into a single package.
- you have proven that the ASN.1 codec we are using in ApacheDS is
slower and more complex than the one in Kerby
- regardless of Kerby/apacheDS relation, we want to use the best
possible codec.

That being said, I think that releasing the ASN.1 lib first could be a
sweat plan :
- first, it's almost ready : it works, the code is quite clean, and it's
- second, that would be an excellent exercise for the kerby project :
cutting a small release first to learn how it's done would benefit
everyone in Kerby
- third, this will be a shared library anyway. I can forsee that the
ASN.1 lib would be of use for other projects as an independent
sub-project (like MINA or the LDAP API)

Now, this might be just me. wdyt ?
>>> AFAICT, Kerby is having its own code to manage communication. We depend on MINA.
If we have to get rid of MINA, that's fine.
> Ah good point. It's a major issue we need to address. Since ApacheDS uses MINA I thought
there is no good not to use it for the Kerberos functionality. We may enhance kerby KDC server
to support plugin network mechanism, which needs some work, but won't be very hard.

MINA was used in ApacheDS for a good reason : back in 2003, when
ApacheDS was started, Alex didn't want to spend some time on the network
layer (I can understand) and decided to check on the internet if there
was already something wrapping NIO available. He found Netty 1, and
asked Trustin to join the project. It became MINA.

At some point (2007?) MINA become a top level project, and we continued
using it, but it became more and more complex. Many features added in
MINA were not necessary for ApacheDS, and I must admit I spent a HUGE
portion of time fixing bugs in MINA to get it working fine (well, more
or less). In any case, I do think MINA 2 is overly complex, and the way
we use it in ApacheDS is clearly sub-optimal.

Now, the problem is that replcaing it with something else will be
difficult. When it comes to Kerberos, we have to support TCP *and* UDP,
plus the switch from TCP to UDP. We also have to deal with concurrent
requests in ApacheDS, where one request can potentially be interrupted
by an Abandon request (that means we can't block a session at all). That
makes it quite complex to handle, if we were to rewite the whole system.

Bottom line, I think that MINA 3 should address those issues, but there
is a 3/6 months effort to put there, and we have many other more urgent
tasks to complete before.

So, here, we should have a discussion.
> I thought we could first focus on ApacheDS side (then Studio), attempting to use Kerby
to replace the old Kerberos codes.
This would be a post-Kerby 1.0 task, agreed.

> It's nicer to do it piece by piece and get the changes in incrementally, but I guess
some time it's hard to break down into tasks.

IMHO, it's better to do it piece by piece, because in order to do that,
you have to decouple the code. If the code is highly coupled, we will
face some bigger issues later on.

> Maybe we can have a branch for the attempt if anyone would help with? Without some trying,
something won't expose. It may be not possible to come to the good time point when Kerby is
well prepared for ApacheDS, on the other hand, trying to do the integration work will expose
some issues/enhance opportunities/adapting things in Kerby side.

A branch might really be an option. Nothing replace real world
experimentation :-)

If you have some time, feel free to play around ! I'm just trying to
proviude some feedbacks and perception of teh potential roadblocks,
certainly not saying we should not try ! Sometime it's better to unleash
people, and let them experiment. If they don't succeed, at least they
will understand better why !

Colm O hEigeartaigh

Talend Community Coder
View raw message