directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: AP-REP message
Date Mon, 04 Jan 2016 10:40:59 GMT
Hi Emmanuel,

I understand your review comments and actually they're very insightful. I may be a little
nervous but I did have to convey the current situation the codes in so that you can aware
it why I would insist on some points for myself. Some of the codes are still initial and lacking
something, that does not mean we shouldn't the project. As you may understand, a project may
be released out with some features still in its experimental status unless the feature itself
isn't claimed to be available. Kerberos contains quite a few extensions and updates since
4210, as you may be noted, we're incrementally implementing them one by one, and some of them
may come across some RCs or even formal releases. So all in all, please don't be surprised
when you see still immature codes when you're doing the great review. Thanks.

While you're reviewing, I would try to address your questions in timely manner because not
only we should, but also I think it's important for the project's long term, though it's not
so exciting as writing something new.

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Monday, January 04, 2016 5:51 PM
To: kerby@directory.apache.org
Subject: Re: AP-REP message

Le 04/01/16 08:39, Zheng, Kai a écrit :
> I know and agree with the point you made here. What I would say is that, our Kerberos
implementation codes are still lacking many things and to be evolved fast. We may see many
classes, variables, methods and codes are not referenced in the existing codes, it's normal
because we have so much to fill yet. Given you have reviewed quite a few of the codes, I guess
you might understand that why we define and write those classes or methods not used yet, because
in many times we follow a RFC spec, or a fixed pattern and make up many of them, either for
completeness, for the future we'll use them at all, or just for our customers they need the
library to do something.

I'm fine with that. It's just that as there is no documentation in the code, it's hard to
know where it's coming from, and what it might be good for in the near future. A simple Javadoc
saying 'not used atm, will be in the near future', or 'part of a RFC draft http://blah' would
help.
>
> Decrypted result in Kerberos is surely to be passed elsewhere and handled in various
procedures or components, considering it often contains many information. We just can't do
all the logics in a single place because that would result in a very large function or class.
I guess the codes you noted are still very initial for now, which means we have many things
to fill in the places. Sorry I haven't checked the codes you mentioned, but I would if our
Kerby codes are going to be close to the final status with all the available functionalities
existing in MIT Kerberos already fine implemented.

We are talking about releasing RC2, and we already have released a RC1 (Release Candidate)
;-) So maybe it's premature to call it a Release Candidate, and we should name them Milestone
?

>  Obviously, we're not. Sadly, we won't in a fair term future. Otherwise it's unfair,
Kerberos has evolved past more than twenty years, we just can't catch up with the mainstream
simply in one or two years.

The simple fact that our Kerberos Implementation at ApacheDS haven't reach a full coverage
of the Kerberos specifications in 10 years is just making your point ;-)


Sorry if my mails make you think I find it wrong, I'm just trying to point fingers on parts
that, in my opinion, might need some improvements. If I'm lucky, I find bugs, or areas where
more work need to be done, and that's the purpose of this review.

It's also for me a way to get involved in this code...

Thanks Kai ! I'll keep the methods at the moment.


Mime
View raw message