directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: About Haox project
Date Tue, 23 Dec 2014 23:41:42 GMT
Hi Stefan,

Thanks for your welcome and great feedback.

>> That is a huge plan and vision, I prefer to do smaller steps, but good luck
Yes I quite agree. This plan in the vision might be helpful to serve as a guidance or indication
for the long term effort. Itself won't happen or even make any sense without concrete phases
and steps. I would just keep the vision in mind. Would you think it works or not having the
sub-project using the codebase we work on the implementation incrementally (smaller steps)?
It could be easier, not having to impact Haox violently and break existing users of ApacheDS
Kerberos. Initially, the sub-project is rather like a incubating project and allows to evolve
independently just as other sub-projects do. Meanwhile, ApacheDS itself can decouple from
Kerberos yes again in smaller steps. Then in some time we get to a phase, like mentioned in
the step 2 in the proposal.

>> This proposal also means to separate all the Kerberos functionality out of ApacheDS
so that it "only" remains an LDAP server? I'd support that, this would reduce complexity,
modularization is good.
Yes, I thought so. Looks like we all love this. It's discussion result with Emmanuel and Kiran.


>> Security nightmare. When implementing crypto yourself you need to know what you are
doing and need to react on security issues.
I agree. The codes in that part would definitely need more attention and review. But I would
clarify that the Kerberos crypto doesn't implement its own underlying encryption and MAC algorithms,
it has to rely on existing like JCE. In its layer we follow the related spec and make the
resultant encryption types and checksum types compatible and interoperable with MIT Kerberos.
Kerberos itself is all about security, the crypto is the core part I guess so I understand
your concern. It's possible we use the API and implement a JRE backed crypto. A note is the
Kerberos crypto in JRE isn't complete, like lacking CAMELLIA related etypes. It only works
on server side. On client side if we would support other Java environment, we would need our
own tweaks. We need security experts from the community, Haox is just a beginning, as I said
it's far from ideal. We would have a long journey.

>> Two source files contain header with Oracle copyright and GPL license.
>>This code needs to be replaced. I hope no other code was taken from JDK sources.
Yes, I will clean up such and ensure this. 

Regards,
Kai

-----Original Message-----
From: Stefan Seelmann [mailto:mail@stefan-seelmann.de] 
Sent: Wednesday, December 24, 2014 3:07 AM
To: dev@directory.apache.org
Subject: Re: About Haox project

Hi,

first a warm welcome :)

Just a few first notes, need more time to read the mail again...

* That is a huge plan and vision, I prefer to do smaller steps, but good luck

* This proposal also means to separate all the Kerberos functionality out of ApacheDS so that
it "only" remains an LDAP server? I'd support that, this would reduce complexity, modularization
is good.

* Security nightmare. When implementing crypto yourself you need to know what you are doing
and need to react on security issues.

* Two source files contain header with Oracle copyright and GPL license.
This code needs to be replaced. I hope no other code was taken from JDK sources.

Kind Regards,
Stefan


Mime
View raw message