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:[email protected]] Sent: Wednesday, December 24, 2014 3:07 AM To: [email protected] 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
