RE: Needed changes to Kerby as a result of the introduction of the KdcClientRequest

[Zheng, Kai]

Hi Richard,

Thanks for the patch! It’s in good form. Could you fire a jira for the work and 
I will do a review in this weekend. Thanks.

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Saturday, November 11, 2017 4:45 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Needed changes to Kerby as a result of the introduction of the 
KdcClientRequest

Kai,

Having not created a GIT patch before, I selected all projects, right clicked 
to access the Team menu, selected Create Patch, and entered a file name. 
Attached you'll find the resulting file.

Regards,
Richard

On Fri, Nov 10, 2017 at 3:45 AM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Sounds good, Gerard.

I’d like to see your patch and then have better idea. I understand the purpose 
and the proposed change.

Regards,
Kai

From: Gerard Gagliano [mailto:g...@apache.org<mailto:g...@apache.org>]
Sent: Friday, November 10, 2017 6:12 AM
To: dev@directory.apache.org<mailto:dev@directory.apache.org>
Subject: Needed changes to Kerby as a result of the introduction of the 
KdcClientRequest

We've been working to make the changes necessitated by the introduction of the 
KdcClientRequest class and the associated calling parameter changes.

Many data items needed by the authorization data backend code are not included 
in the KdcClientRequest class as defined in the 1.1.0-SNAPSHOT.  Modification 
of this class to include the necessary data items includes a reference to the 
KrbIdentity class.

This creates a circular dependency between the kerb-core project and the 
kerb-identity project.  The circular dependency can be resolved by moving 
KrbIdentity from kerb-identity to kerb-core.  Another suggestion is to more it 
to kerb-common.  And another suggestion is to remove KdcClientRequest from 
package ….kerb.type.kdc as all other classes in that package are ASN1 classes 
and this is not.

Moving the classes as follows resolves the circular dependency:
KdcClientRequest from kerb-core, and
KrbIdentity from kerb-identity
To kerb-common — package org.apache.kerby.kerberos.kerb.request

In addition, a dependency on kerb-common will be added to kerb-identity.

Without objection, we’ll move these classes.  If there is a better way than 
this, please suggest.

Thanks.




--
Richard M Feezel
rfee...@gmail.com<mailto:rfee...@gmail.com>

RE: Needed changes to Kerby as a result of the introduction of the KdcClientRequest

[Zheng, Kai]

Sounds good, Gerard.

I’d like to see your patch and then have better idea. I understand the purpose 
and the proposed change.

Regards,
Kai

From: Gerard Gagliano [mailto:g...@apache.org]
Sent: Friday, November 10, 2017 6:12 AM
To: dev@directory.apache.org
Subject: Needed changes to Kerby as a result of the introduction of the 
KdcClientRequest

We've been working to make the changes necessitated by the introduction of the 
KdcClientRequest class and the associated calling parameter changes.

Many data items needed by the authorization data backend code are not included 
in the KdcClientRequest class as defined in the 1.1.0-SNAPSHOT.  Modification 
of this class to include the necessary data items includes a reference to the 
KrbIdentity class.

This creates a circular dependency between the kerb-core project and the 
kerb-identity project.  The circular dependency can be resolved by moving 
KrbIdentity from kerb-identity to kerb-core.  Another suggestion is to more it 
to kerb-common.  And another suggestion is to remove KdcClientRequest from 
package ….kerb.type.kdc as all other classes in that package are ASN1 classes 
and this is not.

Moving the classes as follows resolves the circular dependency:
KdcClientRequest from kerb-core, and
KrbIdentity from kerb-identity
To kerb-common — package org.apache.kerby.kerberos.kerb.request

In addition, a dependency on kerb-common will be added to kerb-identity.

Without objection, we’ll move these classes.  If there is a better way than 
this, please suggest.

Thanks.

RE: Kerby Update

[Zheng, Kai]

+ Directory.

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Monday, October 23, 2017 10:38 AM
To: ke...@directory.apache.org
Subject: RE: Kerby Update

Cool!!

Thanks Jiajia & Frank for working on this this, cross realm trust support! I 
thought this makes Kerby a much further step, towards a decent and standalone 
Kerberos implementation.

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Monday, October 23, 2017 9:22 AM
To: ke...@directory.apache.org
Subject: Kerby Update

Hi all,

Recently we have implemented the cross-realm authentication support, KDC in one 
realm can authenticate users in a different realm, so it allows client from 
another realm to access the cluster. Cross-realm authentication is accomplished 
by sharing a secret key between the two realms. In both backends should have 
the krbtgt service principals for realms with same passwords, key version 
numbers, and encryption types. We have used this feature in Hadoop cluster, 
after establishing cross realm trust between two secure Hadoop clusters with 
their own realms, copying data between two secure clusters can work now. And 
this support also can be used to build trust relationship with MIT Kerberos KDC 
and we have tested compatibility.

Here is the document about setting up cross realm:
https://github.com/apache/directory-kerby/blob/trunk/docs/cross-realm.md

Thanks,
Jiajia

RE: SVN and git mirror cleanup

[Zheng, Kai]

LGTM. Thanks Emmanuel!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, October 23, 2017 8:22 AM
To: dev@directory.apache.org
Subject: Re: SVN and git mirror cleanup

No objection from me.


Thanks for dealing with this, Stefan !


Le 22/10/2017 à 21:06, Stefan Seelmann a écrit :
> Hi all,
>
> we have some svn git mirrors that IMHO don't make sense anymore:
>
> directory-clients
> * Last real change was back in 2010
> * Replaced by ldap-api and kerby projects
> * I'd also move it in SVN to "deceased" [1]
>
> directory-daemon
> * Was moved to "deceased" [1] in 2010
>
> directory-installers
> * Was moved to "deceased" [1] in 2010
>
> directory-shared
> * Replaced by directory-ldap-api
>
> directory-skins
> * Will be moved to new buildtools git repo
>
> directory-studio-plugin
> * Was moved to "deceased" [1] in 2015, we now use Tycho
>
> See
> * https://git.apache.org/ and ctrl-f for "directory-" and
> * https://github.com/apache?utf8=%E2%9C%93=directory-
>
> I'll create an infra ticket to remove them within the next days if 
> there is no objection.
>
> Kind Regards,
> Stefan
>
> [1] https://svn.apache.org/repos/asf/directory/deceased/

--
Emmanuel Lecharny

Symas.com
directory.apache.org

RE: [VOTE] Apache Directory Studio 2.0.0.v20170904-M13 release

[Zheng, Kai]

Cool!! Thanks for the info.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, September 06, 2017 4:02 PM
To: dev@directory.apache.org
Subject: Re: [VOTE] Apache Directory Studio 2.0.0.v20170904-M13 release



Le 06/09/2017 à 09:57, Zheng, Kai a écrit :
> Non-binding +1 on the release.
>
> Great to see the major movement to be rebased on Neon 3 and Java 8. Thanks.

FTR, I'm working on a branch that runs into Oxygen : it works just fine too :-)

--
Emmanuel Lecharny

Symas.com
directory.apache.org

RE: [VOTE] Apache Directory Studio 2.0.0.v20170904-M13 release

[Zheng, Kai]

Non-binding +1 on the release.

Great to see the major movement to be rebased on Neon 3 and Java 8. Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, September 06, 2017 3:52 PM
To: Apache Directory Developers List 
Subject: Re: [VOTE] Apache Directory Studio 2.0.0.v20170904-M13 release

My +1.


Built the packages and ran the project, ran the installer, checked teh N 
files : all is ok for me.


Great job, Stefan, as usual !


Le 04/09/2017 à 23:45, Stefan Seelmann a écrit :
> Hi all,
>
> after 10 month I'd like to propose the next Studio release. It's 
> mainly a bugfix release, the platform is updated to Eclipse Neon.3, 
> and now Java 8 is now the minimum JVM version. The full release notes are 
> here:
> https://issues.apache.org/jira/projects/DIRSTUDIO/versions/12338643
>
> SVN tag:
> https://svn.apache.org/repos/asf/directory/studio/tags/2.0.0.v20170904
> -M13/
>
> Nexus staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-
> 1147
>
> Distribution packages:
> https://dist.apache.org/repos/dist/dev/directory/studio/2.0.0.v2017090
> 4-M13/
>
> Please cast your vote:
> [ ] +1 : release Apache Directory Studio 2.0.0.v20170904-M13 [ ] ± 0 : 
> I don't care [ ] -1 : No, don't release Apache Directory Studio 
> 2.0.0.v20170904-M13
>
> Kind Regards,
> Stefan

--
Emmanuel Lecharny

Symas.com
directory.apache.org

RE: [VOTE] - Release Apache Kerby 1.0.1

[Zheng, Kai]

Thanks Colm for this!

The fixed issues look great to have and the release artifacts are good.

+1 from me.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, August 30, 2017 6:31 PM
To: ke...@directory.apache.org; Apache Directory Developers List 

Subject: [VOTE] - Release Apache Kerby 1.0.1

This is a vote to release Apache Kerby 1.0.1.

Issues fixed:

https://issues.apache.org/jira/projects/DIRKRB/versions/12340574

Git tag:

https://github.com/apache/directory-kerby/tree/kerby-all-1.0.1

Artifacts:

https://repository.apache.org/content/repositories/orgapachedirectory-1146/

In particular, the source artifacts:

https://repository.apache.org/content/repositories/orgapachedirectory-1146/org/apache/kerby/kerby-all/1.0.1/

+1 from me.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [Vote] Switch to git for Apache LDAP API 2.0

[Zheng, Kai]

+1.

Is there any tool to convert and remain the commit history? If there is any 
downside, this probably is one if we can’t keep the logs.

Regards,
Kai

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Friday, August 04, 2017 4:19 PM
To: Apache Directory Developers List 
Subject: Re: [Vote] Switch to git for Apache LDAP API 2.0

+1, most of the projects at Apache I'm involved with now have switched to git.
Colm.

On Fri, Aug 4, 2017 at 9:16 AM, Emmanuel Lécharny 
> wrote:
Hi guys,


"It was the best *of* times, it was the worst *of* times" (Dickens)


it's a pretty big change : switching away from SVN to git. We are using
svn from the very beginning, so to speak 14 years, and it's probablu
time to use a more efficient and modern VCC system. To most of you, that
should be a no brainer, and we already have a few sub-projects using git
at Diectory (Fortress, kerby).


However, I think it's important to get this vote out, as it's gong to
impact the project as a whole.


Note that it will just be for teh API atm, but the other projects will
most certainly migrate sooner or later (ApacheDS, Studio, Mavibot and
teh site)


So :


[ ] +1 : switch Apache LDAP API to git

[ ] +/-0 : I don't mind

[ ] -1 : Keep going with SVN


-1 is not a veto, feel free to speak your mind. The idea is to be sure
we are all on the same page here : I don't feel compelled to switch, but
I do think it would make it easier for us to work on the project, and
for external users to push PRs.


Thanks !


--
Emmanuel Lecharny

Symas.com
directory.apache.org



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Ldap API 2.0 roadmap

[Zheng, Kai]

Sounds exciting and great move! Any more legacy to get rid of by the chance?

Sent from iPhone

> 在 2017年8月3日，20:04，Emmanuel Lécharny  写道：
> 
> Hi guys,
> 
> 
> I didn't had time last week-end to post this mail.
> 
> We have released the Apache LDAP API 1.0 a few weeks ago. This was a
> great acomplishment, after years of efforts. It was not perfect, but
> still, 'good enough' is probably the correct description.
> 
> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> 
> So let's thing bigger : If we go for a 2.0, I also suggest we move to
> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
> also switch to Java 8 and will use this API 2.0 in M25, and teh next
> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
> 
> 
> I would also suggest we switch to git for the API, now that 1.0 is out.
> SVN is outdated, and it's quite an anchor for us anyway (I have to use
> svn *and* git daily, it makes things more complex...). Nor sure we
> should'nt move to git for all teh projects, but startng wih teh API
> sounds reasonable atm. In any case, I'll write another mail for this change.
> 
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 
> 
> Many thanks !
> 
> 
> -- 
> Emmanuel Lecharny
> 
> Symas.com
> directory.apache.org
> 

RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

>> I think Kerby is a promising project, but I don't think it has the community 
>> yet to justify being a TLP.
Yeah, Kerberos isn't the cool thing that many developers are eager to work on. 
There are many reasons. So we probably shouldn't expect a large community for 
this, it may never happen.

On the other hand, here is the community, as the Apache Directory community. If 
we have a TLP, we can duplicate the PMCs and committers. Kerby itself does have 
already diverse committers.

My two cents. The question is, would a TLP make Kerby and Directory more 
healthy, or make us more happy, or make new contributors more easy? Simpler, if 
a TLP can help build and attract a better community for Kerby, we probably 
should go.

Thanks Colm for the work to use Kerby in other ASF projects. It does help. I 
thought we folks here could be able to build a better ecosystem in the security 
domain for Apache world, we have LDAP and Kerberos, the security basics, the 
very good base. IMO, we should have quite a few TLP projects around the two 
basics, instead of ONE monster of so many children projects all here together, 
looking at the Directory hope page. If I'm a developer and want to contribute 
to Kerby, I would be frustrated to figure out the right ML, the right REPO and 
the right relationship/deps with other components. 

Kerby should have the potential, Directory and big data projects can use it. 
The question is, will a TLP make Kerby next solid step?

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Thursday, May 18, 2017 12:34 AM
To: ke...@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

I think Kerby is a promising project, but I don't think it has the community 
yet to justify being a TLP. Hopefully as more Big Data projects adopt it for 
testing it will continue to grow. Apache WSS4J and CXF have switched to use 
Kerby 1.0.0 for integeration testing. I will shortly submit a patch to Apache 
Ranger to use it as well, as there are no kerberos integration tests done there.

Colm.

On Wed, May 17, 2017 at 3:32 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

>
>
> Le 17/05/2017 à 15:06, Zheng, Kai a écrit :
> > Good ask. Maybe we could address questions like such:
> > 1. How many issues we fixed since RC2 release, any features we've added?
> > 2. A summary about Kerby and high level functionalities list?
> > 3. Some links to the release artifacts and project.
> >
> > Not sure if any best practice here.
>
> The best practice is to send an announcement on annou...@apache.org, 
> but you already know that.
>
> You may want to be a bit broader : please contact pr...@apache.org 
> (Sally Khudairi) if you want some more PR, they would be pleased to 
> help you drafting something that will be pushed to other channels.
>
>
> That being said, you should also start thinking about moving Kerby to 
> a TLP, now that 1.0 is out. Please consider doing so while discussing 
> with press@a.o, so that both moves are done at the same time, in order 
> to have more spotlights on the project.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Any good luck so far? Thanks!

Sent from iPhone

> 在 2017年5月13日，下午9:54，Colm O hEigeartaigh  写道：
> 
> With all +1 votes, this vote passes. I'll do the release.
> 
> Colm.
> 
> On Fri, May 12, 2017 at 12:54 PM, Lucas Theisen 
> wrote:
> 
>> +1
>> 
>>> On May 12, 2017 1:28 AM, "Zeng, Frank"  wrote:
>>> 
>>> Build successfully.
>>> 
>>> Run kadmin, kinit, klist successfully.
>>> 
>>> 
>>> 
>>> non-binding +1 from me.
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> Frank
>>> 
>>> 
>>> 
>>> *From:* Colm O hEigeartaigh [mailto:cohei...@apache.org
>>> ]
>>> *Sent:* Wednesday, May 10, 2017 6:14 PM
>>> *To:* ke...@directory.apache.org; Apache Directory Developers List <
>>> dev@directory.apache.org>
>>> *Subject:* [VOTE] - Release Apache Kerby 1.0.0 (take II)
>>> 
>>> 
>>> 
>>> This is (the second) vote to release Apache Kerby 1.0.0. We had to cancel
>>> the first vote after Emmanuel identified some issues with the NOTICE +
>>> licenses for the two Kerby distributions. The distributions now correctly
>>> include the Netty NOTICEs and licenses of modified components, and SLF4J
>>> copyright notice + license.
>>> 
>>> Issues fixed:
>>> 
>>> https://issues.apache.org/jira/browse/DIRKRB/fixforversion/12332775
>>> 
>>> Maven Artifacts:
>>> 
>>> https://repository.apache.org/content/repositories/orgapache
>>> directory-1130/
>>> 
>>> In particular the source:
>>> 
>>> https://repository.apache.org/content/repositories/orgapache
>>> directory-1130/org/apache/kerby/kerby-all/1.0.0/
>>> 
>>> Git tag:
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=directory-kerby.gi
>>> t;a=commit;h=b0e8f9da3cdb494c82d62c956ee35a53a52ac0ce
>>> 
>>> 
>>> 
>>> +1 from me.
>>> 
>>> Colm.
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Colm O hEigeartaigh
>>> 
>>> Talend Community Coder
>>> http://coders.talend.com
>>> 
>> 
> 
> 
> -- 
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

[Zheng, Kai]

Thanks Colm for coming to this step!

My colleagues have given it more tests and verified it works fine. 

So my +1 on the release.

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Wednesday, May 10, 2017 8:38 PM
To: Apache Directory Developers List ; 
cohei...@apache.org; ke...@directory.apache.org
Subject: RE: [VOTE] - Release Apache Kerby 1.0.0 (take II)

+1

Items checked:

1.  Built successfully with jdk1.8.0_40

2.  All tests passed.

3.  Checked the tools.

Thanks
Jiajia

From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Wednesday, May 10, 2017 6:14 PM
To: ke...@directory.apache.org; Apache Directory Developers List 

Subject: [VOTE] - Release Apache Kerby 1.0.0 (take II)

This is (the second) vote to release Apache Kerby 1.0.0. We had to cancel the 
first vote after Emmanuel identified some issues with the NOTICE + licenses for 
the two Kerby distributions. The distributions now correctly include the Netty 
NOTICEs and licenses of modified components, and SLF4J copyright notice + 
license.
Issues fixed:

https://issues.apache.org/jira/browse/DIRKRB/fixforversion/12332775
Maven Artifacts:

https://repository.apache.org/content/repositories/orgapachedirectory-1130/
In particular the source:

https://repository.apache.org/content/repositories/orgapachedirectory-1130/org/apache/kerby/kerby-all/1.0.0/
Git tag:

https://git-wip-us.apache.org/repos/asf?p=directory-kerby.git;a=commit;h=b0e8f9da3cdb494c82d62c956ee35a53a52ac0ce

+1 from me.
Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: MIA for a bit...

[Zheng, Kai]

Congrats Emmanuel indeed so you're upgraded!

Best regards,
Kai

Sent from iPhone

在 2017年3月3日，下午4:54，Pierre Smits 
> 写道：

Congratulations, Emmanuel. I trust both mother and daughter are well.

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Fri, Mar 3, 2017 at 1:58 AM, Lucas Theisen 
> wrote:
Wow!  Congratulations.

On Mar 2, 2017 9:13 AM, "Emmanuel Lécharny" 
> wrote:
Hi !


just for you to know, I may be MIA for a while, or at least way less
responsive : My wife just gave birth to our wonderful daughter today,
and I'm afraid it's going to be our priority number one in the next few
weeks :-)


Thanks !

--
Emmanuel Lecharny

Symas.com
directory.apache.org

RE: Apache Directory Blog

[Zheng, Kai]

Yeah, pretty cool!! Thanks for the takings!

Regards,
Kai

From: john eipe [mailto:john77e...@gmail.com]
Sent: Friday, February 17, 2017 7:21 PM
To: Apache Directory Developers List 
Subject: Re: Apache Directory Blog

This is awesome. Let the blogs flow in...

Regards,
John Eipe

“The Roots of Violence: Wealth without work, Pleasure without conscience, 
Knowledge without character, Commerce without morality, Science without 
humanity, Worship without sacrifice, Politics without principles”
- Mahatma Gandhi

On 17 February 2017 at 15:32, Pierre Smits 
> wrote:
Hi All,

Our Blog has gone live. And thanks go to Emmanual who made this possible AND 
posted the first article.

You can find it here (and don't forget to bookmark and/or to (re)tweet about it 
;) ): https://blogs.apache.org/directory/

Have you subscribed to our twitter account (@ApacheDS)?

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

RE: Who's @apachecon in seville?

[Zheng, Kai]

It's a pity I won't be there. Fortunately a Kerby guy Wei from my side will do 
and I suggest he attend the meetup then. Wei worked on Kerby GSSAPI part and 
tuned Kerby KDC server much.

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Tuesday, November 08, 2016 3:56 AM
To: Apache Directory Developers List 
Subject: Re: Who's @apachecon in seville?


> On Nov 7, 2016, at 7:41 AM, Colm O hEigeartaigh  wrote:
> 
> 
> I'll be there as well, looking forward to meeting up.

Great, see you soon!

Shawn

Sync up

[Zheng, Kai]

Hi folks,

I'd like to update that our tech lead Jiajia on Kerby project is taking a long 
leave from the team and has delivered a very cute baby. Congratulations to 
Jiajia! After some basic ramp up, Sammi will help with her role in my side and 
try to move on. Thanks for the support.

Regards,
Kai

RE: Kerby Remote KAdmin

[Zheng, Kai]

Hi Shawn,

I don't have a deep dive in that, but I thought what's been going is to get it 
work first in kerby remote client -> kerby admin server, in a protocol approach 
(XDR) aligned with MIT Kerberos admin. After that effort will be made to get it 
work with MIT admin using kerby admin client. Yan Yan is the major contributor 
but she had left the team so I'm not sure she will keep the contribution or 
not. Another contributor Qing from the team is working on a remote web UI 
interface at his willing.

Regards,
Kai

-Original Message-
From: SHAWN E SMITH [mailto:se...@psu.edu] 
Sent: Friday, August 05, 2016 10:14 PM
To: Apache Directory Developers List 
Subject: Kerby Remote KAdmin

All,

We've been working on getting the protocol working against an MIT Kerb 
instance.  Based on byte tracing in wireshark we think we're pretty close, but 
something is still not lining up cleanly.  Has anyone else done a deep dive on 
this that may be able to provide some feedback on what we're doing?  I'd like 
to find a good way to share what we're doing, but most of it is outside of core 
kerby so I'm not sure where to put it for others to see it.

Thanks,
Shawn

Any fool can write code that a computer can understand. Good programmers write 
code that humans can understand.
--Martin Fowler 

Shawn Smith
Director of Software Engineering
Administrative Information Services
814-321-5227
se...@psu.edu

https://keybase.io/ussmith

RE: Rethinking Mavibot...

[Zheng, Kai]

Hi Lucas,

I understand what you meant and totally agree. That’s why in the past years I 
would spend lots of spare time working on a pure Java Kerberos binding, Apache 
Kerby. However, for the backend part, as it regards to users’ data, it must be 
strong so better to delegate to 3rd party offerings. You could think about 
this, developing another backend like Mavibot, would be how hard as it is 
being, while working on our core specific things such as LDAP and Kerberos, 
even given enough resources, right. It’s good to have the current Java 
offering, and we can leverage it to do the unit testing, and fallback to some 
platforms, but basing on the fact that we have/support a strong backend for the 
most typical platform.

Yes, the backend support should be pluggable and configurable so potentially 
the server can support whatever backend if the user would. Currently Apache 
Kerby goes that way.

Regards,
Kai

From: Lucas Theisen [mailto:lucasthei...@pastdev.com]
Sent: Tuesday, June 28, 2016 9:26 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: Rethinking Mavibot...


My 10 cents...  a pure Java solution is much better for many reasons:

1) easier to use, don't have to think about a different version per OS
2) easier to build (obviously)
3) easier to test, don't have to worry about inconsistency introduced by 
different builds of the native lib
4) ...

That said, being able to plug in a different backend via configuration is 
always valuable, and already supported, so I certainly wouldn't complain if 
somebody wrote an adapter for the native storage engine.

Lucas
On Jun 28, 2016 8:57 AM, "Zheng, Kai" 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Yeah. It sounds like a great choice to consider 
https://github.com/deephacks/lmdbjni. It's still in updating. Would we proceed 
on this?

Anyway, will play around it this week and see if any concerns.

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org<mailto:smckin...@apache.org>]
Sent: Monday, June 27, 2016 9:10 PM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Re: Rethinking Mavibot...


> On Jun 27, 2016, at 7:29 AM, Emmanuel Lécharny 
> <elecha...@gmail.com<mailto:elecha...@gmail.com>> wrote:
>
> Here is what I would suggest :
>
> - LMDB is an obvious candidate if we want to use something that
> exists, and which is proven to work.
> - There are a coupld of existing bindings for LMDB :
> https://github.com/deephacks/lmdbjni,
> https://github.com/chirino/lmdbjni
> (which is 3 years old)
> - We need to ensure that we have a build for Linux, Windows an MacOSX.
> A project like https://github.com/deephacks/lmdb might help
>
> We also need someone wanting to play around the idea.

This is a good discussion.

I agree with Kai, having a good and stable backend / database is critical to 
this project’s future.  OTOH Emmanuel’s point that we’re open source 
(volunteers) is an obvious inhibiting factor.

So, do we have SWAG’s for the number of hours required for both approaches, 
i.e. apacheds w/ LMDB or Mavibot?

If we can have an apacheds & lmdb release in a few weeks, where mavibot might 
take many months, it might be worth a shot.  Otherwise we should stay the 
course and not get sidetracked.

(my two cents)

Shawn

RE: Rethinking Mavibot...

[Zheng, Kai]

This sounds nice. 

In my view, we should probably start with the most popular platform like Linux 
and fallback to the current Java offering on other platforms that we don't 
support yet due to all kinds of constraints like resources and the library 
limit. Incrementally we can add to support more and more.

By supporting a partition using LMDB, what did you mean? A partition using LMDB 
coexists with a partition using other means meanwhile? Thanks for the 
clarifying.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Saturday, July 02, 2016 5:03 AM
To: Apache Directory Developers List 
Subject: Re: Rethinking Mavibot...

As a matter of fact, things are moving in the LMDB landscape :

https://github.com/lmdbjava/lmdbjava

There is still some need of a Windows build for LMDB, but still, I think that 
would be great to have a partition that uses LMDB. Just for the sake of 
consitency.

RE: VOTE : add Steve Moyer, Chris Harm, Shawn Smith and Alex Haskell as Apache Directory project committers

[Zheng, Kai]

I'm sorry, but why this go public? Any process change?

+1 on the vote itself. I had worked with Steve before about Kerberos some bit. 

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, July 01, 2016 9:57 PM
To: Apache Directory Developers List 
Subject: VOTE : add Steve Moyer, Chris Harm, Shawn Smith and Alex Haskell as 
Apache Directory project committers

Hi guys,


now that we have accepted the SCIM code contribution, we have to vote in the 
four contributors :


Alex Askell

Chris Harm

Shawn Smith

Steve Moyer


I personally met Steve 2 years ago (time flies !!!), and Shawn McKinney have 
worked with them a lot recently (Shawn, you can probably confirm and bring some 
more information). I do think they will be good new committers, and they for 
sure understand what is Open Source.


So :


[ ] +1 : vote them as committers

[ ] +/- 0 : no opinion


[ ] -1 : No, don't vote them in.


Thanks a lot !

RE: Rethinking Mavibot...

[Zheng, Kai]

Yeah. It sounds like a great choice to consider 
https://github.com/deephacks/lmdbjni. It's still in updating. Would we proceed 
on this?

Anyway, will play around it this week and see if any concerns.

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Monday, June 27, 2016 9:10 PM
To: Apache Directory Developers List 
Subject: Re: Rethinking Mavibot...


> On Jun 27, 2016, at 7:29 AM, Emmanuel Lécharny  wrote:
> 
> Here is what I would suggest :
> 
> - LMDB is an obvious candidate if we want to use something that 
> exists, and which is proven to work.
> - There are a coupld of existing bindings for LMDB :
> https://github.com/deephacks/lmdbjni, 
> https://github.com/chirino/lmdbjni
> (which is 3 years old)
> - We need to ensure that we have a build for Linux, Windows an MacOSX. 
> A project like https://github.com/deephacks/lmdb might help
> 
> We also need someone wanting to play around the idea.

This is a good discussion.

I agree with Kai, having a good and stable backend / database is critical to 
this project’s future.  OTOH Emmanuel’s point that we’re open source 
(volunteers) is an obvious inhibiting factor.

So, do we have SWAG’s for the number of hours required for both approaches, 
i.e. apacheds w/ LMDB or Mavibot?

If we can have an apacheds & lmdb release in a few weeks, where mavibot might 
take many months, it might be worth a shot.  Otherwise we should stay the 
course and not get sidetracked.

(my two cents)

Shawn

RE: Rethinking Mavibot...

[Zheng, Kai]

That's right. We have to choose a broadly supported backend and include all the 
supported binary packages. Basically, we could have the current Mavibot or JDBM 
as the fallback. We should really really get it work in the best on the most 
typical platforms, such as Linux, and wouldn't worry too much about the else.

Regards,
Kai 

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, June 27, 2016 7:03 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Rethinking Mavibot...

Le 27/06/16 à 12:49, Zheng, Kai a écrit :
> Thanks so much for the full explanation, Emmanuel. Sorry for my asking again. 
>
>>> Otherwise, we could use LMDB, with a JNI wrapper. That is an option. But I 
>>> have no idea what it would cost us in term of packaging.
> The packaging isn't really so much a problem. There is a nice way handling 
> this: the binary package could be put into the jar just as a resource and 
> while starting up it can be dynamically extracted, putted into a runtime 
> folder to be loaded. Many Java projects do this way. 

Yes, but that would require a built package for all the targets.

RE: Rethinking Mavibot...

[Zheng, Kai]

>> Transaction has to be started explicitely from the LDAP layer...
Yeah, I agree. But that doesn't mean the LDAP layer has to implement the 
transaction support itself. It just needs to aware, start and end the 
transaction when performing add/delete/update operations.

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, June 27, 2016 6:52 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Rethinking Mavibot...

Le 27/06/16 à 12:33, Zheng, Kai a écrit :
> Yes, I agree. Is it possible to be a lightweight wrapper on top of the 
> plugined DB enginene, for example, we wouldn't need to support the 
> transaction stuffs by ourselves? 

No. Transaction has to be started explicitely from the LDAP layer, which means 
either youhave to use a DB backend that support cross-B-trees transactions or 
you have to implement it above the DB backend, which is clearly not simple, and 
will not be simple.

> Is there any LDAP-centric engine already

There is no such thing.

> or allowing to do the mapping very directly?
The mapping is simple (kind of), as soon as you know how to use a key-value 
store.


There is no magic involved.

RE: Rethinking Mavibot...

[Zheng, Kai]

I really think the community need to think about this seriously because it 
regards how the parent project would evolve in the long term. Lacking a strong 
and solid LDAP server backend, it would shade our many efforts in other 
aspects. Considering we're lacking of enough hands here and implementing a high 
reliability and performance in favor of modern hardware capabilities would take 
lots of time, I strongly suggest we look at alternative options, and proceed in 
much easier way.

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Monday, June 27, 2016 6:49 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: Rethinking Mavibot...

Thanks so much for the full explanation, Emmanuel. Sorry for my asking again. 

>> Otherwise, we could use LMDB, with a JNI wrapper. That is an option. But I 
>> have no idea what it would cost us in term of packaging.
The packaging isn't really so much a problem. There is a nice way handling 
this: the binary package could be put into the jar just as a resource and while 
starting up it can be dynamically extracted, putted into a runtime folder to be 
loaded. Many Java projects do this way. 

If we could go this way, I would love to do this and support in other aspects 
as well as possible, because it would sound very promising to come up a high 
performance and high reliability LDAP server for the Apache world.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, June 27, 2016 6:03 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Rethinking Mavibot...

Le 27/06/16 à 08:07, Zheng, Kai a écrit :
> Thanks for the update.
>
> It looks like to me there is much work to do. Is there any alternative 
> option? I'm still thinking that if we could leverage any existing back end 
> implementation, so we could focus on the LDAP specific logic for the master 
> server component...this is worth being considered because in today's industry 
> there are so many B-TREE's implementations already.
I think we already discussed that matter months ago. I also think that many 
don't understand why we *need* somthing like Mavibot. But let me try to explain 
again...


Back in 2006, we knew that we were going to have troubles with our choice 
(JDBM). Back then, we had little choice though :
- JDBM was the only open source, license compatible B-tree implementation in 
Java available.
- We had other more important issues to cope with.

However, during the Austin Apache Conference, during which CiuchDB was 
announced, we had a long discussion with Alex, Pierre-Arnaud and Ersin about 
the fact that we would need a MVCC based backend. Sadly, CouchDB was written in 
Erlang, so we had to wait.

We waited until 2011, where it appears that concurrent searches and updates 
would eventually generate errors (typically, some searches would fail). We 
added a hell lot of locks, up to the point it was impossible to do a search 
while doing an update, which was a very expensive penalty to pay. At teh same 
time, we started to look at alternatives, that does not include a rewite. Some 
guy started to implement MVCC on top of JDBM, but the result was not pleasant : 
if for any reason you forgot to close a cursor, the server would go west in a 
matter of minute. We can't forces the client to carrefully close their cursor, 
it was simply not an option, so we ditched the work.

What alternative did we have ? Not so much : Berkeley DB has been bought by 
Oracle, and the JE wasn't available with a compatible license. And as of today, 
there aren't any MVCC B-Tree implementation that I know of, with a compatible 
license. So we are in a kind of dead lock.

Funny enough, at the very same time, OpenLDAP has started to work on the exact 
same piece of code, for the exact same reason (BDB has changed its license, and 
some data corruption could occur under certain circonstances, requiering a tool 
to repair the database). So we new we weren't in bad company !

Bottom line, I started to work on a replacement for JDBM, which get pushed in 
the repository on january 2012 ( I started to work on that in the mid 2011). 
Kiran ported ApacheDS to use Mavibot as a backend around Srping 2013, and we 
now have an ApacheDS server that *works* with Mavibot. Not only that, but it's 
also faster than JDBM.

Is it enough ? No. For one single reason : Mavibot with no transaction support 
won't be any better than JDBM, for the exact same reasons : if we have a crash, 
we will potentially ends with a corrupted database (less often than JDBM but 
still). It's way better though because we can't have a failure during a search 
while updates are done, and courruption could be fixed easily.

Mavibot brings some other extra bonuses : we now can inject data in bulk mode, 
which is orders of magnitude faster than adding data when the server is up

RE: Rethinking Mavibot...

[Zheng, Kai]

Thanks so much for the full explanation, Emmanuel. Sorry for my asking again. 

>> Otherwise, we could use LMDB, with a JNI wrapper. That is an option. But I 
>> have no idea what it would cost us in term of packaging.
The packaging isn't really so much a problem. There is a nice way handling 
this: the binary package could be put into the jar just as a resource and while 
starting up it can be dynamically extracted, putted into a runtime folder to be 
loaded. Many Java projects do this way. 

If we could go this way, I would love to do this and support in other aspects 
as well as possible, because it would sound very promising to come up a high 
performance and high reliability LDAP server for the Apache world.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, June 27, 2016 6:03 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Rethinking Mavibot...

Le 27/06/16 à 08:07, Zheng, Kai a écrit :
> Thanks for the update.
>
> It looks like to me there is much work to do. Is there any alternative 
> option? I'm still thinking that if we could leverage any existing back end 
> implementation, so we could focus on the LDAP specific logic for the master 
> server component...this is worth being considered because in today's industry 
> there are so many B-TREE's implementations already.
I think we already discussed that matter months ago. I also think that many 
don't understand why we *need* somthing like Mavibot. But let me try to explain 
again...


Back in 2006, we knew that we were going to have troubles with our choice 
(JDBM). Back then, we had little choice though :
- JDBM was the only open source, license compatible B-tree implementation in 
Java available.
- We had other more important issues to cope with.

However, during the Austin Apache Conference, during which CiuchDB was 
announced, we had a long discussion with Alex, Pierre-Arnaud and Ersin about 
the fact that we would need a MVCC based backend. Sadly, CouchDB was written in 
Erlang, so we had to wait.

We waited until 2011, where it appears that concurrent searches and updates 
would eventually generate errors (typically, some searches would fail). We 
added a hell lot of locks, up to the point it was impossible to do a search 
while doing an update, which was a very expensive penalty to pay. At teh same 
time, we started to look at alternatives, that does not include a rewite. Some 
guy started to implement MVCC on top of JDBM, but the result was not pleasant : 
if for any reason you forgot to close a cursor, the server would go west in a 
matter of minute. We can't forces the client to carrefully close their cursor, 
it was simply not an option, so we ditched the work.

What alternative did we have ? Not so much : Berkeley DB has been bought by 
Oracle, and the JE wasn't available with a compatible license. And as of today, 
there aren't any MVCC B-Tree implementation that I know of, with a compatible 
license. So we are in a kind of dead lock.

Funny enough, at the very same time, OpenLDAP has started to work on the exact 
same piece of code, for the exact same reason (BDB has changed its license, and 
some data corruption could occur under certain circonstances, requiering a tool 
to repair the database). So we new we weren't in bad company !

Bottom line, I started to work on a replacement for JDBM, which get pushed in 
the repository on january 2012 ( I started to work on that in the mid 2011). 
Kiran ported ApacheDS to use Mavibot as a backend around Srping 2013, and we 
now have an ApacheDS server that *works* with Mavibot. Not only that, but it's 
also faster than JDBM.

Is it enough ? No. For one single reason : Mavibot with no transaction support 
won't be any better than JDBM, for the exact same reasons : if we have a crash, 
we will potentially ends with a corrupted database (less often than JDBM but 
still). It's way better though because we can't have a failure during a search 
while updates are done, and courruption could be fixed easily.

Mavibot brings some other extra bonuses : we now can inject data in bulk mode, 
which is orders of magnitude faster than adding data when the server is up and 
running.


Otherwise, we could use LMDB, with a JNI wrapper. That is an option. But I have 
no idea what it would cost us in term of packaging. Right now, ApacheDS comes 
as a bundled package, or as an installer for Linux, Mac OSX and Windows. Having 
a dependency on a binary component might be a real trouble when it comes to 
package it properly. ATM, I'm not willing to spend some time on this aspect.

Last, not least, Mavibot is *NOT* a B-tree implementation. It's a MVCC 
(Multi-Version Concurrency Control B-tree implementation
(https://en.wikipedia.org/wiki/Multiversion_concurrency_control) which is 
*VERY* different. The critical aspect is the MVCC part, this is what guarantees 
consistancy, and lock

RE: Rethinking Mavibot...

[Zheng, Kai]

Yes, I agree. Is it possible to be a lightweight wrapper on top of the plugined 
DB enginene, for example, we wouldn't need to support the transaction stuffs by 
ourselves? Is there any LDAP-centric engine already or allowing to do the 
mapping very directly?

Regards,
Kai

-Original Message-
From: Howard Chu [mailto:h...@symas.com] 
Sent: Monday, June 27, 2016 6:15 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Rethinking Mavibot...

Emmanuel Lécharny wrote:
> Le 27/06/16 à 08:07, Zheng, Kai a écrit :
>> Thanks for the update.
>>
>> It looks like to me there is much work to do. Is there any alternative 
>> option? I'm still thinking that if we could leverage any existing back end 
>> implementation, so we could focus on the LDAP specific logic for the master 
>> server component...this is worth being considered because in today's 
>> industry there are so many B-TREE's implementations already.
> I think we already discussed that matter months ago. I also think that 
> many don't understand why we *need* somthing like Mavibot. But let me 
> try to explain again...

As an aside, there are two things going on here - you need both an underlying 
DB engine, and you need an LDAP-centric "backend" on top of it. Even if you 
tried to plug in an off-the-shelf DB engine, you still need to implement the 
backend that uses it.

-- 
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Rethinking Mavibot...

[Zheng, Kai]

Thanks for the update.

It looks like to me there is much work to do. Is there any alternative option? 
I'm still thinking that if we could leverage any existing back end 
implementation, so we could focus on the LDAP specific logic for the master 
server component...this is worth being considered because in today's industry 
there are so many B-TREE's implementations already.

Sorry for the bothering and interrupting.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Sunday, June 26, 2016 7:15 PM
To: Apache Directory Developers List 
Subject: Rethinking Mavibot...

Hi guys,


now that I'm done with the LDAP API release and ApacheDS release, I'd like to 
dedicate some time to complete Mavibot, as it's a critical part of the server.


The current status is not exactly perfect. It's usable, but there is no support 
for transaction across B-trees, which makes it as brittle as JDBM when it comes 
to use it in ApacheDS (simply because an update impact many B-Trees, so it has 
to be an all-or-nothing operation, which implies a cross-B-trees transaction).

We have started to implement it in a branch (single-value) where other changes 
have been applied :

- no support for multi-values (way too complex to support in this first
version)

- no support for in-memory B-trees (not critical, makes everything more
complex)


Here is how I see transactions being implemented :

- The recordManager will be responsible for creating new transactions.

- each operation on any B-tree will require an extra parameter, the transaction 
that it belongs to

- transaction will not last forever, a default timeout of 30 mins will be used, 
to avoid long-lasted transactions that would make the database grow without 
control (keep in mind that a read transaction holds a revision until it's 
aborted, which leads to holding old pages on disk).


So bottom line, here is what an operation will looks like :


RecordManager recordManager = new RecordManager( "MyDatabase" );

Transaction readTransaction = recordManager.beginReadTransaction();

BTree btree = recordManager.getManagedTree( 
readTransaction, "MyBtree" );

boolean hasKey = btree.haskey( 1L );

readTransaction.abort(); // COuld have been commit();


More to come in the following weeks.

RE: [Vote] Accept Scim contribution

[Zheng, Kai]

Thanks Shawn! It sounds very promising for the parent project.

+1.

Regards,
Kai

From: SHAWN E SMITH [mailto:se...@psu.edu]
Sent: Monday, June 27, 2016 1:02 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [Vote] Accept Scim contribution

Hi Kai,

All fair questions.  Our initial efforts in the SCIM spectrum was an offshoot 
of eSCIMo, with the primary work being done by Steve Moyer.  Once the spec was 
finalized we did a first principles redesign in an attempt to make a fully 
compliant library implementation.  This effort was to support an identity 
system that we've built and are running.  The identity system is built out from 
many Apache directory components; Fortress for RBAC/ABAC, and the LDAP API to 
be specific.  We're watching the Kerby work anxiously because it will allow me 
to retire a C++ shim service I wrote for doing Kerberos administrative tasks.

I think the Directory project has all of the tools to build out  a first class 
identity solution and I'm hoping our SCIM implementation will be a natural fit 
to the existing tool set.

Thanks again for the consideration.

Shawn

"The programmer … works only slightly removed from pure thought-stuff.
He builds his castles in the air, from air, creating by exertion of the 
imagination."
— Fred Brooks

Shawn Smith
Director of Software Engineering
Administrative Information Services
Penn State University
814-321-5227
se...@psu.edu<mailto:se...@psu.edu>

https://keybase.io/ussmith

________
From: "Zheng, Kai" <kai.zh...@intel.com<mailto:kai.zh...@intel.com>>
To: "Apache Directory Developers List" 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Sent: Saturday, June 25, 2016 1:21:21 PM
Subject: RE: [Vote] Accept Scim contribution

I would love to see the eSCIMo component being revived and the two similar 
projects being consolidated. Considering the place holder is ready there, we 
could probably trust the party and give them the space to develop in the 
direction, without too much overhead incurred to the left of us I guess.

However, I have some questions to have to ask. Why is Apache Directory a 
natural place for the guys to consider contributing the project to? How is it 
linked with the other components? What’s the rational? Sorry I may have missed 
some discussions before.

+1 on the vote once above questions are addressed. Thanks.

Regards,
Kai

From: Kiran Ayyagari [mailto:kayyag...@apache.org]
Sent: Saturday, June 25, 2016 3:30 PM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Re: [Vote] Accept Scim contribution



On Sat, Jun 25, 2016 at 5:14 AM, Emmanuel Lécharny 
<elecha...@gmail.com<mailto:elecha...@gmail.com>> wrote:
Hi guys,


two months ago, Shawn Smith wrote us to inform the Apache Directory
project that he wanted to contribute the project he is working on with
Steve Moyer, Christopher Harm and Alex Haskell.


We have discussed about this proposal one month ago, but due to some
highly busy agenda on my side, I sadly forgot to start a vote (and I
have to be frank : would have I started the vote, I would not have had
teh time to deal with the consequences of a positive vote). Now that I'm
done with teh API and ApacheDS releae, and my work on the API branch, my
agenda has cleared up.


So here is a formal vote for the integration of this project in the
apache Directory project, as a sub project. My opinion is that this
would replace eSCIMo that has never been released, unless Kiran decide
otherwise. We would naturally use the existing eSCIMo project web-site
as a plcae-holder. One idea would also be that we could keep the eSCIMo
name, or use SCIMple-Identity, but it would be really up to the people
to decide.
I am fine with using eSCIMo name and site

If we get a positive vote, we will then have to vote the 4 people who
participated to the code as committer - if they want to pursue their
work, of course ! -.  But first, let's vote


[ ] +1, accept the SCIMple-Identity project as a subproject of Apache
Directory
+1, however I may not be able to spend time on this cause of the work I am
doing on another SCIM server (written in Go) and other paid work.

[ ] +/-0 No opinion

[ ] -1 : don't accept the SCIMple-Identity project.


For the record, the code base is available at
https://github.com/PennState/SCIMple-Identity, and it's already under a
AL 2.0 license
(https://github.com/PennState/SCIMple-Identity/blob/develop/LICENSE)

Many thanks, and trully sorry fo rthe delayed vote !
Thank you
Kiran Ayyagari
http://keydap.com

RE: [Vote] Accept Scim contribution

[Zheng, Kai]

I would love to see the eSCIMo component being revived and the two similar 
projects being consolidated. Considering the place holder is ready there, we 
could probably trust the party and give them the space to develop in the 
direction, without too much overhead incurred to the left of us I guess.

However, I have some questions to have to ask. Why is Apache Directory a 
natural place for the guys to consider contributing the project to? How is it 
linked with the other components? What’s the rational? Sorry I may have missed 
some discussions before.

+1 on the vote once above questions are addressed. Thanks.

Regards,
Kai

From: Kiran Ayyagari [mailto:kayyag...@apache.org]
Sent: Saturday, June 25, 2016 3:30 PM
To: Apache Directory Developers List 
Subject: Re: [Vote] Accept Scim contribution



On Sat, Jun 25, 2016 at 5:14 AM, Emmanuel Lécharny 
> wrote:
Hi guys,


two months ago, Shawn Smith wrote us to inform the Apache Directory
project that he wanted to contribute the project he is working on with
Steve Moyer, Christopher Harm and Alex Haskell.


We have discussed about this proposal one month ago, but due to some
highly busy agenda on my side, I sadly forgot to start a vote (and I
have to be frank : would have I started the vote, I would not have had
teh time to deal with the consequences of a positive vote). Now that I'm
done with teh API and ApacheDS releae, and my work on the API branch, my
agenda has cleared up.


So here is a formal vote for the integration of this project in the
apache Directory project, as a sub project. My opinion is that this
would replace eSCIMo that has never been released, unless Kiran decide
otherwise. We would naturally use the existing eSCIMo project web-site
as a plcae-holder. One idea would also be that we could keep the eSCIMo
name, or use SCIMple-Identity, but it would be really up to the people
to decide.
I am fine with using eSCIMo name and site

If we get a positive vote, we will then have to vote the 4 people who
participated to the code as committer - if they want to pursue their
work, of course ! -.  But first, let's vote


[ ] +1, accept the SCIMple-Identity project as a subproject of Apache
Directory
+1, however I may not be able to spend time on this cause of the work I am
doing on another SCIM server (written in Go) and other paid work.

[ ] +/-0 No opinion

[ ] -1 : don't accept the SCIMple-Identity project.


For the record, the code base is available at
https://github.com/PennState/SCIMple-Identity, and it's already under a
AL 2.0 license
(https://github.com/PennState/SCIMple-Identity/blob/develop/LICENSE)

Many thanks, and trully sorry fo rthe delayed vote !
Thank you
Kiran Ayyagari
http://keydap.com

RE: Kerberos Login fails through Apache Directory Studio

[Zheng, Kai]

I don’t have the experience, but guess you could try different encryption types 
and see if any different result.

And, what JDK are you using?

Regards,
Kai

From: siva venkat [mailto:sivar...@gmail.com]
Sent: Wednesday, June 15, 2016 11:12 PM
To: dev@directory.apache.org; ke...@directory.apache.org
Subject: Kerberos Login fails through Apache Directory Studio

Hi,

I am using latest ApacheDS 
2.0.0-M21 , for Kerberose 
login, I followed all steps mentioned in 
http://directory.apache.org/apacheds/kerberos-ug/4.2-authenticate-studio.html .
I am getting error"javax.security.auth.login.LoginException: Integrity check on 
decrypted field failed (31)" when "Require Pre-Authentication By Encrypted 
TimeStamp" checked.
I am getting error "javax.security.auth.login.LoginException: Checksum Failed" 
when "Require Pre-Authentication By Encrypted TimeStamp" is unchecked.

[cid:ii_iph0izth0_155549b7daf5f5d9]
​
Can you please tell how to fix this issue ?
Seems many other folks facing this issue, see this link 
http://stackoverflow.com/questions/23140518/apacheds-and-kerberos-setup.
Thanks,
Siva

FW: kerby security@ email

[Zheng, Kai]

Hi,

In the site http://directory.apache.org/ the Security just links to 
http://www.apache.org/security . So I guess we don't have a dedicated security 
mailing list, right? Do we need one? My preference would be yes.

Regards,
Kai

-Original Message-
From: Steve Loughran [mailto:ste...@hortonworks.com] 
Sent: Thursday, June 09, 2016 9:16 PM
To: Zheng, Kai <kai.zh...@intel.com>
Subject: kerby security@ email


What's the process for reporting any security issue related to kerby? Is there 
security@ alias, or should I just email private@ —and what comes after the @ 
symbol?

(nothing serious BTW, just want to get some rehersals in before something 
important surfaces)

-steve

RE: Kerby migration in Apache Directory?

[Zheng, Kai]

Thanks Yan for your great work on the remote kadmin support and now the taking 
on kpasswd module!

AFAIK, there is no real work on kpasswd module or the change password protocol 
support, though there was some discussion about that.

Regards,
Kai

-Original Message-
From: Yan, Yan A [mailto:yan.a@intel.com] 
Sent: Tuesday, May 31, 2016 10:01 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: Kerby migration in Apache Directory?

Hi guys,

Recently I am working on *remote kadmin* in kerby, and it has been half 
finished.
I would like to know that is there anyone working on *kpassword* module?
If no one, I can take this work since I am already familiar with 
*kadmin* module.

Best regards,
Yan

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Monday, May 30, 2016 5:23 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: Kerby migration in Apache Directory?

IMO, it would make more sense to do the Kerby integration as part of ApacheDS 
2.0 GA.

On the other hand, in Kerby the password change protocol and kpasswd tool is 
still to be implemented, which is supported by ApacheDS. I don't see other 
weakness.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Sunday, May 29, 2016 1:38 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Kerby migration in Apache Directory?

Le 29/05/16 à 02:28, Zheng, Kai a écrit :
> It's good to discuss and clarify the gaps left.
>
>>> it's a bit premature atm.
> Would you clarify some bit about this?
Sure : we have *many* things going on in ApacheDS atm, adding the intergartion 
of Kerby right now will be just overkilling. The high priority is to get the 
LDAP API 1.0 out, then ApacheDS 2.0 GA out and Studio released.

RE: Kerby migration in Apache Directory?

[Zheng, Kai]

Sounds great and make sense to me! Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, May 30, 2016 5:33 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Kerby migration in Apache Directory?

Le 29/05/16 à 23:23, Zheng, Kai a écrit :
> IMO, it would make more sense to do the Kerby integration as part of ApacheDS 
> 2.0 GA.
Our schedule is to first get Mavibot fixed, to get rid of the database 
corruptionw e have in JDBM. Once done, we geta  20 out and immediately start 
with a 3.0 branch.

I really, rzally want to get rid of those Milestones, which are a little bit 
ridiculous, IMO. As is, I do think that ApacheDS 3.0 would perfectly be a 
candidate for a Kerby integration.

RE: Kerby migration in Apache Directory?

[Zheng, Kai]

IMO, it would make more sense to do the Kerby integration as part of ApacheDS 
2.0 GA.

On the other hand, in Kerby the password change protocol and kpasswd tool is 
still to be implemented, which is supported by ApacheDS. I don't see other 
weakness.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Sunday, May 29, 2016 1:38 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Kerby migration in Apache Directory?

Le 29/05/16 à 02:28, Zheng, Kai a écrit :
> It's good to discuss and clarify the gaps left.
>
>>> it's a bit premature atm.
> Would you clarify some bit about this?
Sure : we have *many* things going on in ApacheDS atm, adding the intergartion 
of Kerby right now will be just overkilling. The high priority is to get the 
LDAP API 1.0 out, then ApacheDS 2.0 GA out and Studio released.

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

I committed it to allow more time to exercise and test. For the backend change, 
I believe we'll need more elegant way like modular/pluggable authorization 
support. We can do that when have more thoughts and experience.

Thanks Gerard and Richard both for the major contribution, filling the gap in 
authorization domain!!

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Friday, May 27, 2016 8:41 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Great discussions, Richard and Emmanuel! I would suggest we accept the change 
and let it run some time doing some tests against MIT kinit/KDC. Anyway the 
behavior can be easily changed back if later found it impacts too big. For the 
authorization data change in backend, I would agree that it's a simple way to 
work. 

+1 on the patch attached in DIRKRB-542. If no other concern I would commit it 
in the weekend. Thanks!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Thursday, May 26, 2016 12:38 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Le 26/05/16 à 04:17, Richard Feezel a écrit :
> Kai,
>
> I recall that the Kerberos specifications indicate that empty lists
> (sequences) should not be included in the ASN.1 encoded byte stream. 
> Thus the correct representation of items that are empty in object 
> space is with NULL, not with a tagged field with no elements.

That's the same thing, IMO :

"The Kerberos protocol does
   not semantically distinguish between an absent optional SEQUENCE OF
   type and a present optional but empty SEQUENCE OF type."

Usinhg Null or an empty list should result in the same behavior, when 
generating the ASN.1 stream.

In ApacheDS Kerbeors implementation, we schoose to create an empty list instead 
of seting the padata field to null if we have no padata. What is important is 
not to transmit the emtpy list in teh ASN.1 stream :


// The PD-DATA if any -
if ( paData.size() > 0 )
{
// The tag
buffer.put( ( byte ) KerberosConstants.KDC_REQ_PA_DATA_TAG );
buffer.put( TLV.getBytes( paDataLength ) );

// The sequence
buffer.put( UniversalTag.SEQUENCE.getValue() );
buffer.put( TLV.getBytes( paDataSeqLength ) );

// The values
for ( PaData paDataElem : paData )
{
paDataElem.encode( buffer );
}
}

The key here was to avoid NPE. Now, you can perfectly avoid to create such an 
empty list, and to check for null when accessing the padata field.

> We didn't run into very
> many cases, though when we did we fixed them by adding the necessary 
> IF test in the patch.
> But these were found based on running tests and seeing NPE's thrown at 
> run time, not on a survey of the code to try to identify all the 
> possible failure points. We didn't feel competent to make such a 
> survey given our limited familiarity with the code structure. I 
> believe the correct way to conduct such a survey would be to go to the 
> IETF specifications and identify all optional fields, then search the 
> code for all references to the objects corresponding to these fields.
There are 3 use cases in the Kerberos RFC :

KDC_REQ padata

KDC-REQ-BODY additional-tickets

KDC-REP padata


>
> Regarding authorization data: given the open architecture, and 
> vendor-proprietary nature, of authorization data I believe you would 
> have a very difficult time trying to think of all the different back 
> end data elements to include in the principal identity object. I 
> suppose you could include a Map type structure of name value pairs, 
> but I'd be concerned about the amount of effort expended to construct 
> that data in the back end, only to have the majority of it be ignored 
> by the authorization data plugins.
>
> I'm afraid the relationship between back end implementations and 
> authorization data implementations is too close to develop an 
> efficient generalized API between them that would meet the needs of 
> all vendors. I believe any generalized API between back end 
> implementations and authorization data handlers MUST support arbitrary 
> and proprietary communications between these two elements.

Agreed.

RE: Kerby migration in Apache Directory?

[Zheng, Kai]

It's good to discuss and clarify the gaps left.

>> it's a bit premature atm.
Would you clarify some bit about this?

I'm thinking that if we have some conclusion, we can work towards that. IMO, it 
would be good to do this after Kerby 1.0.0 release is out, but we need to know 
what needs to be done to meet with it.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, May 27, 2016 10:36 PM
To: Apache Directory Developers List 
Subject: Re: Kerby migration in Apache Directory?

Le 27/05/16 à 15:42, Colm O hEigeartaigh a écrit :
> Hi all,
>
> Do we have a plan or timeline to replace the older Kerberos code in 
> Apache Directory with Kerby? If not, does it make sense to start discussing 
> it?

We definitively will have to have this discussion, it's a bit premature atm.

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

Great discussions, Richard and Emmanuel! I would suggest we accept the change 
and let it run some time doing some tests against MIT kinit/KDC. Anyway the 
behavior can be easily changed back if later found it impacts too big. For the 
authorization data change in backend, I would agree that it's a simple way to 
work. 

+1 on the patch attached in DIRKRB-542. If no other concern I would commit it 
in the weekend. Thanks!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, May 26, 2016 12:38 PM
To: Apache Directory Developers List 
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Le 26/05/16 à 04:17, Richard Feezel a écrit :
> Kai,
>
> I recall that the Kerberos specifications indicate that empty lists
> (sequences) should not be included in the ASN.1 encoded byte stream. 
> Thus the correct representation of items that are empty in object 
> space is with NULL, not with a tagged field with no elements.

That's the same thing, IMO :

"The Kerberos protocol does
   not semantically distinguish between an absent optional SEQUENCE OF
   type and a present optional but empty SEQUENCE OF type."

Usinhg Null or an empty list should result in the same behavior, when 
generating the ASN.1 stream.

In ApacheDS Kerbeors implementation, we schoose to create an empty list instead 
of seting the padata field to null if we have no padata. What is important is 
not to transmit the emtpy list in teh ASN.1 stream :


// The PD-DATA if any -
if ( paData.size() > 0 )
{
// The tag
buffer.put( ( byte ) KerberosConstants.KDC_REQ_PA_DATA_TAG );
buffer.put( TLV.getBytes( paDataLength ) );

// The sequence
buffer.put( UniversalTag.SEQUENCE.getValue() );
buffer.put( TLV.getBytes( paDataSeqLength ) );

// The values
for ( PaData paDataElem : paData )
{
paDataElem.encode( buffer );
}
}

The key here was to avoid NPE. Now, you can perfectly avoid to create such an 
empty list, and to check for null when accessing the padata field.

> We didn't run into very
> many cases, though when we did we fixed them by adding the necessary 
> IF test in the patch.
> But these were found based on running tests and seeing NPE's thrown at 
> run time, not on a survey of the code to try to identify all the 
> possible failure points. We didn't feel competent to make such a 
> survey given our limited familiarity with the code structure. I 
> believe the correct way to conduct such a survey would be to go to the 
> IETF specifications and identify all optional fields, then search the 
> code for all references to the objects corresponding to these fields.
There are 3 use cases in the Kerberos RFC :

KDC_REQ padata

KDC-REQ-BODY additional-tickets

KDC-REP padata


>
> Regarding authorization data: given the open architecture, and 
> vendor-proprietary nature, of authorization data I believe you would 
> have a very difficult time trying to think of all the different back 
> end data elements to include in the principal identity object. I 
> suppose you could include a Map type structure of name value pairs, 
> but I'd be concerned about the amount of effort expended to construct 
> that data in the back end, only to have the majority of it be ignored 
> by the authorization data plugins.
>
> I'm afraid the relationship between back end implementations and 
> authorization data implementations is too close to develop an 
> efficient generalized API between them that would meet the needs of 
> all vendors. I believe any generalized API between back end 
> implementations and authorization data handlers MUST support arbitrary 
> and proprietary communications between these two elements.

Agreed.

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

It’s pretty cool and my great honor to see you in the conference, Lucas, Shawn 
and Alex!! We talked much and it’s a lot of fun, though we’re not able to meet 
together for a Directory discussion… it’s the pity.

What I understood would be, contribution might be hard and we may earn nothing, 
but at least we can have some friends in the world and talk something when we 
meet. Just ping me when you on board to Shanghai, China, someday in future …

Regards,
Kai

From: Zheng, Kai [mailto:kai.zh...@intel.com]
Sent: Thursday, May 12, 2016 12:17 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: RE: Travel to Vancouver and Bay Area

I’m also in. Where is 1230p? Is it in the hotel? Is it possible to have a 
meeting so we might have full time yesterday?

From: Lucas Theisen [mailto:lucasthei...@pastdev.com]
Sent: Wednesday, May 11, 2016 8:48 AM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Re: Travel to Vancouver and Bay Area


I'm in.  Where you wanna meet?
On May 11, 2016 8:35 AM, "Shawn McKinney" 
<smckin...@apache.org<mailto:smckin...@apache.org>> wrote:
I am onsite now.  Lunch @ 1230p today?

Shawn

> On May 9, 2016, at 10:36 PM, Zheng, Kai 
> <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
>
> Sorry I missed this today. Alex I will try to find you on the following days 
> if you’re still there.
>
> Regards,
> Kai
>
> From: akaras...@gmail.com<mailto:akaras...@gmail.com> 
> [mailto:akaras...@gmail.com<mailto:akaras...@gmail.com>] On Behalf Of Alex 
> Karasulu
> Sent: Monday, May 09, 2016 10:39 AM
> To: Apache Directory Developers List 
> <dev@directory.apache.org<mailto:dev@directory.apache.org>>
> Subject: Re: Travel to Vancouver and Bay Area
>
> I'm here if any one from directory wants to connect. Chilling by the 
> escalator for the next couple hours on 2nd floor.
>
> Cheers,
> Alex
>
> On Mon, May 9, 2016 at 9:24 AM, Zheng, Kai 
> <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
> Sounds great Colm! I guess we'd be pretty busy on Wednesday, maybe have the 
> meetup on Thursday?
>
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Monday, May 09, 2016 2:37 AM
> To: Apache Directory Developers List 
> <dev@directory.apache.org<mailto:dev@directory.apache.org>>
> Cc: ke...@directory.apache.org<mailto:ke...@directory.apache.org>
> Subject: Re: Travel to Vancouver and Bay Area
>
> Hi Kai,
>
> I'll be at ApacheCon as well from Wednesday to Friday, it sounds like we have 
> enough people for an Apache Directory meetup ;-)
>
> Colm.
>
>
>
> On Fri, May 6, 2016 at 11:12 PM, Zheng, Kai 
> <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
>
> > Thanks!! A big pity you won't be there but I guess we could eventually
> > be able to meet elsewhere in future!
> >
> > -Original Message-
> > From: Emmanuel Lécharny 
> > [mailto:elecha...@gmail.com<mailto:elecha...@gmail.com>]
> > Sent: Saturday, May 07, 2016 6:07 AM
> > To: ke...@directory.apache.org<mailto:ke...@directory.apache.org>
> > Subject: Re: Travel to Vancouver and Bay Area
> >
> > Le 06/05/16 23:41, Zheng, Kai a écrit :
> > > Hi Shawn, it's great we'll be able to have a meet. Yes, the whole
> > > next
> > week I'll be hanging there.
> >
> > Ra... I wish I could have gone :/
> >
> > Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All
> > my best to all of you, guys !
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Best Regards,
> -- Alex

RE: Scim library contribution

[Zheng, Kai]

Yeah, before it becomes a TLP, there should be something to be done and happen. 
One thing is, have a separate web site. I discussed about this with an Apache 
officer and was told it was doable. There can be found quite a few examples, 
sub project can have standalone web site.

To evolve, we shouldn't keep all things together, to make the parent web site 
crowded and crowded.

Glad to have a new component from PSU!

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Saturday, May 14, 2016 7:16 AM
To: Apache Directory Developers List 
Subject: Re: Scim library contribution


> On May 13, 2016, at 3:40 PM, Emmanuel Lécharny  wrote:
> 
> The rational here is to make sure that we have some common interest in 
> having those projects and the associated people working hand in hand, 
> to create a strong community.

It has been immensely valuable to have the guidance of this project committee.  
It brings extra eyes to our code and processes.

> 
> On May 13, 2016, at 3:40 PM, Emmanuel Lécharny  wrote:
> 
> Fortress was also benefiting from ApacheDS, as all the unit tests are 
> based on it. Now that a 1.0 is out, we can also think about making it 
> a TLP. That would be up to Shawn and Chris to see when it would make 
> sense, but the community around it is small atm.

Agreed.  The community must grow before TLP status makes sense.  Otherwise I 
guess you’re stuck with us cause we’re not giving up anytime soon.   ;-)

Shawn

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

I’m also in. Where is 1230p? Is it in the hotel? Is it possible to have a 
meeting so we might have full time yesterday?

From: Lucas Theisen [mailto:lucasthei...@pastdev.com]
Sent: Wednesday, May 11, 2016 8:48 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Travel to Vancouver and Bay Area


I'm in.  Where you wanna meet?
On May 11, 2016 8:35 AM, "Shawn McKinney" 
<smckin...@apache.org<mailto:smckin...@apache.org>> wrote:
I am onsite now.  Lunch @ 1230p today?

Shawn

> On May 9, 2016, at 10:36 PM, Zheng, Kai 
> <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
>
> Sorry I missed this today. Alex I will try to find you on the following days 
> if you’re still there.
>
> Regards,
> Kai
>
> From: akaras...@gmail.com<mailto:akaras...@gmail.com> 
> [mailto:akaras...@gmail.com<mailto:akaras...@gmail.com>] On Behalf Of Alex 
> Karasulu
> Sent: Monday, May 09, 2016 10:39 AM
> To: Apache Directory Developers List 
> <dev@directory.apache.org<mailto:dev@directory.apache.org>>
> Subject: Re: Travel to Vancouver and Bay Area
>
> I'm here if any one from directory wants to connect. Chilling by the 
> escalator for the next couple hours on 2nd floor.
>
> Cheers,
> Alex
>
> On Mon, May 9, 2016 at 9:24 AM, Zheng, Kai 
> <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
> Sounds great Colm! I guess we'd be pretty busy on Wednesday, maybe have the 
> meetup on Thursday?
>
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh 
> [mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
> Sent: Monday, May 09, 2016 2:37 AM
> To: Apache Directory Developers List 
> <dev@directory.apache.org<mailto:dev@directory.apache.org>>
> Cc: ke...@directory.apache.org<mailto:ke...@directory.apache.org>
> Subject: Re: Travel to Vancouver and Bay Area
>
> Hi Kai,
>
> I'll be at ApacheCon as well from Wednesday to Friday, it sounds like we have 
> enough people for an Apache Directory meetup ;-)
>
> Colm.
>
>
>
> On Fri, May 6, 2016 at 11:12 PM, Zheng, Kai 
> <kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
>
> > Thanks!! A big pity you won't be there but I guess we could eventually
> > be able to meet elsewhere in future!
> >
> > -Original Message-----
> > From: Emmanuel Lécharny 
> > [mailto:elecha...@gmail.com<mailto:elecha...@gmail.com>]
> > Sent: Saturday, May 07, 2016 6:07 AM
> > To: ke...@directory.apache.org<mailto:ke...@directory.apache.org>
> > Subject: Re: Travel to Vancouver and Bay Area
> >
> > Le 06/05/16 23:41, Zheng, Kai a écrit :
> > > Hi Shawn, it's great we'll be able to have a meet. Yes, the whole
> > > next
> > week I'll be hanging there.
> >
> > Ra... I wish I could have gone :/
> >
> > Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All
> > my best to all of you, guys !
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Best Regards,
> -- Alex

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Sorry I missed this today. Alex I will try to find you on the following days if 
you’re still there.

Regards,
Kai

From: akaras...@gmail.com [mailto:akaras...@gmail.com] On Behalf Of Alex 
Karasulu
Sent: Monday, May 09, 2016 10:39 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Travel to Vancouver and Bay Area

I'm here if any one from directory wants to connect. Chilling by the escalator 
for the next couple hours on 2nd floor.

Cheers,
Alex

On Mon, May 9, 2016 at 9:24 AM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Sounds great Colm! I guess we'd be pretty busy on Wednesday, maybe have the 
meetup on Thursday?

Kai

-Original Message-
From: Colm O hEigeartaigh 
[mailto:cohei...@apache.org<mailto:cohei...@apache.org>]
Sent: Monday, May 09, 2016 2:37 AM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Cc: ke...@directory.apache.org<mailto:ke...@directory.apache.org>
Subject: Re: Travel to Vancouver and Bay Area

Hi Kai,

I'll be at ApacheCon as well from Wednesday to Friday, it sounds like we have 
enough people for an Apache Directory meetup ;-)

Colm.



On Fri, May 6, 2016 at 11:12 PM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:

> Thanks!! A big pity you won't be there but I guess we could eventually
> be able to meet elsewhere in future!
>
> -Original Message-
> From: Emmanuel Lécharny 
> [mailto:elecha...@gmail.com<mailto:elecha...@gmail.com>]
> Sent: Saturday, May 07, 2016 6:07 AM
> To: ke...@directory.apache.org<mailto:ke...@directory.apache.org>
> Subject: Re: Travel to Vancouver and Bay Area
>
> Le 06/05/16 23:41, Zheng, Kai a écrit :
> > Hi Shawn, it's great we'll be able to have a meet. Yes, the whole
> > next
> week I'll be hanging there.
>
> Ra... I wish I could have gone :/
>
> Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All
> my best to all of you, guys !
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com



--
Best Regards,
-- Alex

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Sounds great Colm! I guess we'd be pretty busy on Wednesday, maybe have the 
meetup on Thursday?

Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Monday, May 09, 2016 2:37 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Cc: ke...@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area

Hi Kai,

I'll be at ApacheCon as well from Wednesday to Friday, it sounds like we have 
enough people for an Apache Directory meetup ;-)

Colm.



On Fri, May 6, 2016 at 11:12 PM, Zheng, Kai <kai.zh...@intel.com> wrote:

> Thanks!! A big pity you won't be there but I guess we could eventually 
> be able to meet elsewhere in future!
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Saturday, May 07, 2016 6:07 AM
> To: ke...@directory.apache.org
> Subject: Re: Travel to Vancouver and Bay Area
>
> Le 06/05/16 23:41, Zheng, Kai a écrit :
> > Hi Shawn, it's great we'll be able to have a meet. Yes, the whole 
> > next
> week I'll be hanging there.
>
> Ra... I wish I could have gone :/
>
> Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All 
> my best to all of you, guys !
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Thanks!! A big pity you won't be there but I guess we could eventually be able 
to meet elsewhere in future!

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Saturday, May 07, 2016 6:07 AM
To: ke...@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area

Le 06/05/16 23:41, Zheng, Kai a écrit :
> Hi Shawn, it's great we'll be able to have a meet. Yes, the whole next week 
> I'll be hanging there.

Ra... I wish I could have gone :/

Enjoy the trip, and have some nice meeting with Shawn and Lucas ! All my best 
to all of you, guys !

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

Hi Shawn, it's great we'll be able to have a meet. Yes, the whole next week 
I'll be hanging there.

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Saturday, May 07, 2016 5:31 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Cc: ke...@directory.apache.org; fortr...@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area

Hello Kai, I will also be in Vancouver next week between Wednesday and Friday 
attending ApacheCon.  If those dates work with your schedule we should try to 
meet.

Thanks,
Shawn

> On May 6, 2016, at 4:22 PM, Zheng, Kai <kai.zh...@intel.com> wrote:
> 
> Hi,
>  
> I will travel to Vancouver (speak about Apache Kerby) and then Bay Area in 
> the next half a month. Is there anybody here happening to be there too so we 
> could meet? If anything I could help with on the Apache Bigdata Conference, 
> please also let me know.
>  
> Regards,
> Kai

RE: Travel to Vancouver and Bay Area

[Zheng, Kai]

I will be hanging there the whole week. Will be very nice to meet you there, 
Lucas! A pity is the speaking along with the whole security things is at 
Tuesday.

From: Lucas Theisen [mailto:lucasthei...@pastdev.com]
Sent: Saturday, May 07, 2016 5:29 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Cc: ke...@directory.apache.org
Subject: Re: Travel to Vancouver and Bay Area


I'm going to be at both apachecon and bigdata in Vancouver...  Also willing to 
help anyone that needs it.  When will you be speaking?
On May 6, 2016 5:22 PM, "Zheng, Kai" 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Hi,

I will travel to Vancouver (speak about Apache Kerby) and then Bay Area in the 
next half a month. Is there anybody here happening to be there too so we could 
meet? If anything I could help with on the Apache Bigdata Conference, please 
also let me know.

Regards,
Kai

Travel to Vancouver and Bay Area

[Zheng, Kai]

Hi,

I will travel to Vancouver (speak about Apache Kerby) and then Bay Area in the 
next half a month. Is there anybody here happening to be there too so we could 
meet? If anything I could help with on the Apache Bigdata Conference, please 
also let me know.

Regards,
Kai

RE: Next Kerby release

[Zheng, Kai]

Good questions, Pierre.

The documentation for the newly added features will be surely updated. I’m also 
thinking about a separate site for the sub project with all the docs included 
in the source code repo if it sounds good, for some rational I raised some time 
ago. With that experience we could also help build other web sites for other 
components.

The timetable, how about one and a half month? So the target date would be June 
15th. Let’s try it.

Regards,
Kai

From: Pierre Smits [mailto:pierre.sm...@gmail.com]
Sent: Wednesday, April 27, 2016 6:58 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Next Kerby release

How about documentation?

What is the suggested timetable? Knowing that, we can leverage it in our 
communications effort.

Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Apr 27, 2016 at 3:26 AM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Hi folks,

We’re thinking about a new Kerby release with the following feature candidates 
to target:

1.   Kerby authorization support. Gerard side provided the large patch and 
is working on the codes refining.

2.   Remote kadmin API. Yan Yan is working on this, the progress seems good.

3.   GSSAPI implementation base on Kerby library. Wei Zhou is working on 
this, the progress is also looking good.

4.   We also have some important fixes.

What else did I miss here? Is there other good things we could consider for the 
release?

As these are mostly good new things so may need some time to stabilize, I’d 
like to suggest we do it in another candidate release, like RC3.

What would you think about this? If sounds good, let’s target this and prepare 
for it!

Regards,
Kai

RE: Kerby powered

[Zheng, Kai]

Yeah, sure right. Thx Emmanuel.

From: Emmanuel Lecharny [mailto:elecha...@apache.org]
Sent: Wednesday, April 27, 2016 4:16 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Kerby powered

That's a good idea! Don't forget 'Apache' before'Kerby' and the (tm)

Le mercredi 27 avril 2016, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> a écrit :
Hi,

How about adding a section in Kerby main site page mentioning projects powered 
by Kerby?

Would anyone like this to mention your project or company? Please comment, 
thanks.

Let me start the list:

1.   Apache Hadoop;

2.   Apache Calcite;

3.   Apache Directory (?)

Regards,
Kai


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com<http://www.iktek.com>

Kerby powered

[Zheng, Kai]

Hi,

How about adding a section in Kerby main site page mentioning projects powered 
by Kerby?

Would anyone like this to mention your project or company? Please comment, 
thanks.

Let me start the list:

1.   Apache Hadoop;

2.   Apache Calcite;

3.   Apache Directory (?)

Regards,
Kai

Next Kerby release

[Zheng, Kai]

Hi folks,

We're thinking about a new Kerby release with the following feature candidates 
to target:

1.   Kerby authorization support. Gerard side provided the large patch and 
is working on the codes refining.

2.   Remote kadmin API. Yan Yan is working on this, the progress seems good.

3.   GSSAPI implementation base on Kerby library. Wei Zhou is working on 
this, the progress is also looking good.

4.   We also have some important fixes.

What else did I miss here? Is there other good things we could consider for the 
release?

As these are mostly good new things so may need some time to stabilize, I'd 
like to suggest we do it in another candidate release, like RC3.

What would you think about this? If sounds good, let's target this and prepare 
for it!

Regards,
Kai

RE: Eclipse format and cleanup configurations

[Zheng, Kai]

Hi Gerard,

We don’t have such a format file, but it looks a good idea to document the 
format somewhere.
AFAIK, the coding style we’re following is:

1.   Over classical SUN Java coding style;

2.   4 spaces instead of a tab;

3.   4 spaces indent;

4.   120 chars width limit in a line, but mostly preferred, 80 chars;

5.   Don’t reformat if you don’t change the file; only do it for the part 
you’re changing;

6.   No star(*) in imports.

It’s just some loose rules often seen in many ASF projects. In my experience, I 
keep some typical settings in my IDE (I’m an old Eclipse fun, but now prefer 
IDEA) and switch among them according to projects.

Regards,
Kai

From: Gerard Gagliano [mailto:gera...@prodentity.com]
Sent: Friday, April 22, 2016 1:47 AM
To: Apache Directory Developers List 
Subject: Eclipse format and cleanup configurations

Hi,

We’re making modifications on Kerby and keep running into problems with the 
saved formatting.  Is there a current Eclipse copy of configurations (the one I 
located is wy different than the style used).

A reference to it’s location would be greatly appreciated.

Thanks!
Gerard

--

RE: [VOTE] Release Apache Directory Fortress 1.0.0

[Zheng, Kai]

Excellent!! Great job Shawn!!

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, April 13, 2016 5:21 PM
To: Apache Directory Developers List 
Subject: Re: [VOTE] Release Apache Directory Fortress 1.0.0

Packages tested, source code from git tested, signatures tested, N checked, 
we are all good !

Great job Shawn ! years of dedication to finally get a 1.0 out, hat down !

Let's get the beast out !

RE: Increasing social media reach

[Zheng, Kai]

Thanks Pierre. It’s unfortunate for me because I’m not able to tweet or follow, 
otherwise it will surely hit 100 + 1.

Regards,
Kai

From: Pierre Smits [mailto:pierre.sm...@gmail.com]
Sent: Thursday, April 07, 2016 9:42 PM
To: Apache Directory Developers List 
Subject: Increasing social media reach

Hi all,

It pleases me to be able to inform you that today I received a notification 
that our project's tweet account @ApacheDS now reached and bested the milestone 
of 100 followers. While followers come and go, we should not deter in spreading 
the positive vibe and continue to inform the public with messages from the 
project that are meaningfull and without sentiment.

Our community will grow with increased awareness at the site of potential 
adopters and other parties interested in our products and our way of working. A 
way to increase our social media reach is also following thoughtleaders and 
influencers on the subjects of our project and sub projects. If you happen to 
know an interesting party (and their tweet account), please share it and we'll 
investigate following him/her/them/they..

Best regards

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

>> You can run "git checkout 3ba4a47f29d16ad2416b9e999ed9927f40390c66" to be 
>> that early version.
Please do this separately in a new working copy or workspace, to avoid loss of 
your local changes.

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Tuesday, April 05, 2016 9:47 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Cc: ke...@directory.apache.org
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Hi Gerard,
I think this commit 
"https://github.com/apache/directory-kerby/commit/3ba4a47f29d16ad2416b9e999ed9927f40390c66;
 is what Kai said.

You can run "git checkout 3ba4a47f29d16ad2416b9e999ed9927f40390c66" to be that 
early version.

Regards,
Jiajia

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 9:14 AM
To: Apache Directory Developers List
Cc: ke...@directory.apache.org
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

That sounds good.  Could you be specifiec what version to get.  If not can you 
give some guidance about what to look for?

Regards,
g

--

> On Apr 4, 2016, at 5:11 PM, Zheng, Kai <kai.zh...@intel.com> wrote:
> 
> I forgot to mention that, you can check out the very early version of Kerby 
> codebase, where it contains a kerb codec test module originated from 
> JaasLounge library. Starting with it, may make your life easier.
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Zheng, Kai [mailto:kai.zh...@intel.com] 
> Sent: Tuesday, April 05, 2016 7:05 AM
> To: Apache Directory Developers List <dev@directory.apache.org>; 
> ke...@directory.apache.org
> Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Thanks for the sync up Gerard!
> 
> We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
> change may need to take some time to be mature. Anyway it sounds good that 
> you and Richard are working on the refinement. Thanks!
> 
> I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
> it by rebasing it to Kerby.
> http://jaaslounge.sourceforge.net/
> 
> Regards,
> Kai
> 
> -Original Message-
> From: Gerard Gagliano [mailto:gera...@prodentity.com] 
> Sent: Tuesday, April 05, 2016 6:55 AM
> To: Apache Directory Developers List <dev@directory.apache.org>
> Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization
> 
> Kai,
> 
> We are thinking about some additional stuff, but this is all we have done 
> thus far.
> 
> As for tests, Richard is putting some together.  What time frame are you 
> thinking for RC3?
> 
> Also, are you aware of any Java code that can parse MS-PAC?
> 
> Thanks!
> 
> g
> 
> --
>> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
>> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>>  ] 
>> 
>> Kai Zheng commented on DIRKRB-542:
>> --
>> 
>> Is there any update? It can be a major thing for the next RC release. Thanks.
>> 
>>> Kerby Authorization
>>> ---
>>> 
>>>   Key: DIRKRB-542
>>>   URL: https://issues.apache.org/jira/browse/DIRKRB-542
>>>   Project: Directory Kerberos
>>>Issue Type: Sub-task
>>>  Reporter: Gerard Gagliano
>>>  Assignee: Gerard Gagliano
>>>   Attachments: ad.patch, ad2.patch, ad3.patch
>>> 
>>> 
>>> Kerby lacks Authorization classes.  Authorization types from RFC 1510, 
>>> 4120, 4537, 4556, 6711 and 7751 will greatly enhance the usability of Kerby.
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
> 

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

I forgot to mention that, you can check out the very early version of Kerby 
codebase, where it contains a kerb codec test module originated from JaasLounge 
library. Starting with it, may make your life easier.

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Tuesday, April 05, 2016 7:05 AM
To: Apache Directory Developers List <dev@directory.apache.org>; 
ke...@directory.apache.org
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Thanks for the sync up Gerard!

We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
change may need to take some time to be mature. Anyway it sounds good that you 
and Richard are working on the refinement. Thanks!

I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
it by rebasing it to Kerby.
http://jaaslounge.sourceforge.net/

Regards,
Kai

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 6:55 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

We are thinking about some additional stuff, but this is all we have done thus 
far.

As for tests, Richard is putting some together.  What time frame are you 
thinking for RC3?

Also, are you aware of any Java code that can parse MS-PAC?

Thanks!

g

--
> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA) <j...@apache.org> wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>  ] 
> 
> Kai Zheng commented on DIRKRB-542:
> --
> 
> Is there any update? It can be a major thing for the next RC release. Thanks.
> 
>> Kerby Authorization
>> ---
>> 
>>Key: DIRKRB-542
>>URL: https://issues.apache.org/jira/browse/DIRKRB-542
>>Project: Directory Kerberos
>> Issue Type: Sub-task
>>   Reporter: Gerard Gagliano
>>   Assignee: Gerard Gagliano
>>Attachments: ad.patch, ad2.patch, ad3.patch
>> 
>> 
>> Kerby lacks Authorization classes.  Authorization types from RFC 1510, 4120, 
>> 4537, 4556, 6711 and 7751 will greatly enhance the usability of Kerby.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

Thanks for the sync up Gerard!

We don't have concrete plan for RC3 yet. I'm thinking that a major feature or 
change may need to take some time to be mature. Anyway it sounds good that you 
and Richard are working on the refinement. Thanks!

I do know a parser that can parse MS-PAC, ref. below. It won't be hard to use 
it by rebasing it to Kerby.
http://jaaslounge.sourceforge.net/

Regards,
Kai

-Original Message-
From: Gerard Gagliano [mailto:gera...@prodentity.com] 
Sent: Tuesday, April 05, 2016 6:55 AM
To: Apache Directory Developers List 
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Kai,

We are thinking about some additional stuff, but this is all we have done thus 
far.

As for tests, Richard is putting some together.  What time frame are you 
thinking for RC3?

Also, are you aware of any Java code that can parse MS-PAC?

Thanks!

g

--
> On Apr 4, 2016, at 4:47 PM, Kai Zheng (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225212#comment-15225212
>  ] 
> 
> Kai Zheng commented on DIRKRB-542:
> --
> 
> Is there any update? It can be a major thing for the next RC release. Thanks.
> 
>> Kerby Authorization
>> ---
>> 
>>Key: DIRKRB-542
>>URL: https://issues.apache.org/jira/browse/DIRKRB-542
>>Project: Directory Kerberos
>> Issue Type: Sub-task
>>   Reporter: Gerard Gagliano
>>   Assignee: Gerard Gagliano
>>Attachments: ad.patch, ad2.patch, ad3.patch
>> 
>> 
>> Kerby lacks Authorization classes.  Authorization types from RFC 1510, 4120, 
>> 4537, 4556, 6711 and 7751 will greatly enhance the usability of Kerby.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

Thanks Richard for digging into the deep!

If the test failure is the only issue incurred by the desired change, we can 
fix the test anyway. But I’m afraid the impact may be more than that. I 
remembered I had considered to change the behavior, but due to some impacts I 
leave it as it was.

When the patch can compile and have the basic issues resolved, I would look at 
the change and see how to fix the failure.

Regards,
Kai

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Thursday, March 31, 2016 11:51 AM
To: Apache Directory Developers List 
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

PersonnelRecordTest is indeed failing due to changes in Asn1CollectionType.java 
in the patch. Unfortunately we can't simply roll back the changes because the 
changes were made to address a problem with the decoding logic which resulted 
in adding default or empty values to the decoded object when fields were 
missing in the encoded data stream. This is incorrect behavior. Additional 
changes will be necessary to this class to correct the induced problem.

On Wed, Mar 30, 2016 at 9:44 PM, Jiajia Li (JIRA) 
> wrote:

[ 
https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
 ]

Jiajia Li commented on DIRKRB-542:
--

[~gg], thanks for your contribution, I think it will be new achievement for 
Kerby.
Some issues:
1. After applying the patch to trunk, with some tests 
failure(PersonnelRecordTest, SignedDataTest...)
2. Compilation failure(ADAuthenticationIndicators.java)
3. The patch reformatted some original code, then some lines are longer than 80 
characters(ps: Each line should not exceed 80)
4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I think 
some of them can be removed.

> Kerby Authorization
> ---
>
> Key: DIRKRB-542
> URL: https://issues.apache.org/jira/browse/DIRKRB-542
> Project: Directory Kerberos
>  Issue Type: Sub-task
>Reporter: Gerard Gagliano
>Assignee: Gerard Gagliano
> Attachments: ad.patch
>
>
> Kerby lacks Authorization classes.  Authorization types from RFC 1510, 4120, 
> 4537, 4556, 6711 and 7751 will greatly enhance the usability of Kerby.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)



--
Richard M Feezel
rfee...@gmail.com

FW: [jira] [Commented] (DIRKRB-542) Kerby Authorization

[Zheng, Kai]

Let’s discuss this in the Kerby space. Thanks.

Regards,
Kai

From: Li, Jiajia [mailto:jiajia...@intel.com]
Sent: Thursday, March 31, 2016 12:19 PM
To: Apache Directory Developers List 
Subject: RE: [jira] [Commented] (DIRKRB-542) Kerby Authorization

Run “mvn clean package -DskipTests” then with the following Compilation failure:

[ERROR] 
directory-kerby/kerby-kerb/kerb-core/src/main/java/org/apache/kerby/kerberos/kerb/type/ad/ADAuthenticationIndicators.java:[34,9]
 no suitable constructor found for 
AuthorizationDataEntry(org.apache.kerby.asn1.Asn1FieldInfo[],org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType)
[ERROR] constructor 
org.apache.kerby.kerberos.kerb.type.ad.AuthorizationDataEntry.AuthorizationDataEntry(org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType,byte[])
 is not applicable
[ERROR] (actual argument org.apache.kerby.asn1.Asn1FieldInfo[] cannot be 
converted to org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType by method 
invocation conversion)
[ERROR] constructor 
org.apache.kerby.kerberos.kerb.type.ad.AuthorizationDataEntry.AuthorizationDataEntry(org.apache.kerby.kerberos.kerb.type.ad.AuthorizationType)
 is not applicable
[ERROR] (actual and formal argument lists differ in length)
[ERROR] constructor 
org.apache.kerby.kerberos.kerb.type.ad.AuthorizationDataEntry.AuthorizationDataEntry()
 is not applicable

From: Richard Feezel [mailto:rfee...@gmail.com]
Sent: Thursday, March 31, 2016 10:59 AM
To: Apache Directory Developers List
Subject: Re: [jira] [Commented] (DIRKRB-542) Kerby Authorization

I don't believe ADAuthenticationIndicators, note the S at the end belongs. It 
was renamed to singular.

On Wed, Mar 30, 2016 at 10:17 PM, Gerard Gagliano 
> wrote:
There should not be any compilation issues, can you describe the errors?

--
> On Mar 30, 2016, at 7:44 PM, Jiajia Li (JIRA) 
> > wrote:
>
>
>[ 
> https://issues.apache.org/jira/browse/DIRKRB-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219187#comment-15219187
>  ]
>
> Jiajia Li commented on DIRKRB-542:
> --
>
> [~gg], thanks for your contribution, I think it will be new achievement for 
> Kerby.
> Some issues:
> 1. After applying the patch to trunk, with some tests 
> failure(PersonnelRecordTest, SignedDataTest...)
> 2. Compilation failure(ADAuthenticationIndicators.java)
> 3. The patch reformatted some original code, then some lines are longer than 
> 80 characters(ps: Each line should not exceed 80)
> 4. A lot of " @SuppressWarnings("unchecked")" were added in the patch, I 
> think some of them can be removed.
>
>> Kerby Authorization
>> ---
>>
>>Key: DIRKRB-542
>>URL: https://issues.apache.org/jira/browse/DIRKRB-542
>>Project: Directory Kerberos
>> Issue Type: Sub-task
>>   Reporter: Gerard Gagliano
>>   Assignee: Gerard Gagliano
>>Attachments: ad.patch
>>
>>
>> Kerby lacks Authorization classes.  Authorization types from RFC 1510, 4120, 
>> 4537, 4556, 6711 and 7751 will greatly enhance the usability of Kerby.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)



--
Richard M Feezel
rfee...@gmail.com

RE: [VOTE] Release Apache Directory Fortress 1.0-RC42 (Take 2)

[Zheng, Kai]

>> Better vote 0 than casting a +1.
Right, agree!

+0 for the release vote.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, March 24, 2016 4:53 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [VOTE] Release Apache Directory Fortress 1.0-RC42 (Take 2)

Le 24/03/16 09:44, Zheng, Kai a écrit :
> Binding +1.
>
> I haven't got the chance to verify this but would like to trust Stefan and 
> Jiajia. 
Please, don't.

Trust is good, but verification is mandatory to cast a +1.

Better vote 0 than casting a +1.

Thanks !

RE: [VOTE] Release Apache Directory Fortress 1.0-RC42 (Take 2)

[Zheng, Kai]

Binding +1.

I haven't got the chance to verify this but would like to trust Stefan and 
Jiajia. Any way I wouldn't impact the progress due to my lacking the time and 
wish the project to move faster.

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Thursday, March 24, 2016 4:07 PM
To: Apache Directory Developers List 
Subject: RE: [VOTE] Release Apache Directory Fortress 1.0-RC42 (Take 2)

+1 Non-binding

- Build successfully with jdk 1.8.0_40
- Source package signature and checksum are valid


To improve:
Run "mvn apache-rat:check" to check there is no missing license header in 
files, but with one unapproved licenses: DEPENDENCIES under 
fortress-realm-1.0-RC42 folder.


Thanks
Jiajia

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org]
Sent: Sunday, March 20, 2016 3:56 PM
To: Apache Directory Developers List
Subject: [VOTE] Release Apache Directory Fortress 1.0-RC42 (Take 2)

Once again we vote to release of Apache Directory Fortress core, realm, rest 
and web

version=1.0-RC42.  

A temporary tag has been created in git: 1.0-RC42.

The staging repo on Nexus:
https://repository.apache.org/content/repositories/orgapachedirectory-1086/

The source distros:
http://home.apache.org/~smckinney/

Let us vote:
[ ] +1 | Release Fortress core, realm, rest and web 1.0-RC42 [ ] +/-0 | Abstain 
[ ] -1 | Do *NOT* Release Fortress core, realm, rest and web 1.0-RC42

Shawn

RE: [VOTE] Release Apache Directory Fortress 1.0-RC42

[Zheng, Kai]

I'm sorry for my late looking at this, it's just my unfortunate that I can't 
spend more time on the projects here like Kerby.
I checked the instructions Shawned initiated for the release vote, I have to 
say that it's pretty complex or involves much overhead, particularly for me, a 
guy that never has the time to absorb the complexity or beauty of LDAP things. 
It contains 4 repos or packages to check and two backends for the integration 
tests. I'm wondering if the project can be reorganized and consolidated 
together in future so that people just check out the whole from one repo and 
when run mvn package install, then all the necessary basic checks can be done. 
As we're only releasing source packages as done for other projects, we don't 
need have to do the integration tests because that can  be covered by the 
customers, as Stefan mentioned. The consolidating will make the project much 
easier participated by new comers, for an example, the hottest ASF project, 
Spark, it puts all the essential components together, SparkCore, SparkSQL, 
SparkStreaming, machine learning, GraphX and so on, every component itself is 
very large than any piece here. Or Hadoop, it contains HDFS and YARN, all in 
the same repo. Maven has the ability to organize all the levels together. 

I checked the sub-project home page in the Directory site and I had another 
suggestion that we may not have to list the all bugs but instead the major 
features/functionalities updated. People may click and go into details for the 
full bug lists.

For the long term, the Fortress project itself can be alone separated from the 
Directory, which may makes the both sides happy, Fortress can evolve fast in 
its own styles and the parent Directory can be lighter weight focusing on the 
core, basic LDAP and the serber things. It looks to me that to cover all the 
wonderful features, the sub-project page won't be to cover them well and look 
decent.

Overall, right now, for the sub-project, I would think, let we relax some bit, 
let it develop, evolve and release faster and often. Probably same thing to 
Kerby.

Sorry for this inappropriate thoughts on this thread. Will check with my side 
to see if any help here. Thanks all for the hard-working.

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Sunday, March 13, 2016 9:27 AM
To: Apache Directory Developers List 
Subject: Re: [VOTE] Release Apache Directory Fortress 1.0-RC42


> On Mar 12, 2016, at 4:12 PM, Emmanuel Lécharny  wrote:
> 
> The third option that you have not listed : we were extremelly busy 
> until this week-end. I had to work all days and most of the nights for 
> the last 4 days, and I just had time to test Kerby in the train. Today 
> I decided not to open my ciomputer and instead to chop some wood, as 
> we had 2 trees down due to the last tempest. This was an interestung 
> physical exercise that proves that, at 50+, you can still use an axe 
> for more than 2 hours. Chainsaw is also very efficient...
> 
> Bottom line, keep the vote opened, I'm likely to test and vote 
> tomorrow or monday.
> 
> And sorry for the delay...

Emmanuel you of all people deserve to take a day off and yeah chopping wood 
will be good for you.  :-)

No worries, thanks for all of the help you’ve provided up to now.

Shawn

RE: PKINIT client support

[Zheng, Kai]

I thought Jiajia could elaborate some bit about what's exactly the gaps to fill 
for the full PKINIT support.

Regards,
Kai

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Tuesday, February 23, 2016 9:04 AM
To: Apache Directory Developers List <dev@directory.apache.org>; 
ke...@directory.apache.org
Subject: RE: PKINIT client support

Hi Lloyd,

Thanks for the interesting and trying! Unfortunately, right now only Anonymous 
PKINIT is done. The RSA case is still on the going but I believe it's quite 
approaching to the completion. The community is busy with other things of 
higher priority like RC2 releasing, GSSAPI support and kadmin-remote support, 
and very probably we'll be back to the PKINIT completing after some time. 
Please let we know if this sounds good or not for your case, and stay tuned. 
Thanks.

Regards,
Kai

-Original Message-
From: Lloyd Evans [mailto:lev...@vmware.com] 
Sent: Tuesday, February 23, 2016 8:56 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: PKINIT client support

Hi All,

I was hoping to use the client API in Kerby to write some Java code that will 
connect to an MIT Kerberos server using PKINIT — specifically, I have a user 
certificate and key, and want to obtain first a TGT, and then a service ticket. 
Have tried the following idea (using Kerby from the ‘trunk’ branch):

KrbClient client = new KrbClient();

client.setKdcHost(host);
client.setAllowTcp(true);
client.setAllowUdp(true);
client.setKdcTcpPort(TCP_PORT);
client.setKdcUdpPort(UDP_PORT);
client.init();

KOptions requestOptions = new KOptions();
requestOptions.add(PkinitOption.USE_PKINIT);
requestOptions.add(PkinitOption.USING_RSA);
requestOptions.add(KrbOption.CLIENT_PRINCIPAL, principal);

if (APPROACH_ONE) {
// cert and key load ok (are not null), but seem to be ignored
Certificate certificate = readCertificateFile(pemFile);
requestOptions.add(PkinitOption.X509_CERTIFICATE, certificate);

PrivateKey privateKey = readPrivateKeyFile(keyFile);
requestOptions.add(PkinitOption.X509_PRIVATE_KEY, privateKey);
} else {
// identity string set to “/path/to/pem,/path/to/pkcs8key"
requestOptions.add(PkinitOption.X509_IDENTITY, pathTo(pemFile) 
+ "," + pathTo(keyFile));
}

TgtTicket tgt = client.requestTgt(requestOptions);



but the server keeps complaining that “received_cert is null”, which I assume 
means the user cert is not being included in the request. Can anyone tell me if 
either (1) what I want to do isn’t really implemented yet, or (2) I am missing 
something.

Thanks
 - Lloyd

RE: PKINIT client support

[Zheng, Kai]

Hi Lloyd,

Thanks for the interesting and trying! Unfortunately, right now only Anonymous 
PKINIT is done. The RSA case is still on the going but I believe it's quite 
approaching to the completion. The community is busy with other things of 
higher priority like RC2 releasing, GSSAPI support and kadmin-remote support, 
and very probably we'll be back to the PKINIT completing after some time. 
Please let we know if this sounds good or not for your case, and stay tuned. 
Thanks.

Regards,
Kai

-Original Message-
From: Lloyd Evans [mailto:lev...@vmware.com] 
Sent: Tuesday, February 23, 2016 8:56 AM
To: Apache Directory Developers List 
Subject: PKINIT client support

Hi All,

I was hoping to use the client API in Kerby to write some Java code that will 
connect to an MIT Kerberos server using PKINIT — specifically, I have a user 
certificate and key, and want to obtain first a TGT, and then a service ticket. 
Have tried the following idea (using Kerby from the ‘trunk’ branch):

KrbClient client = new KrbClient();

client.setKdcHost(host);
client.setAllowTcp(true);
client.setAllowUdp(true);
client.setKdcTcpPort(TCP_PORT);
client.setKdcUdpPort(UDP_PORT);
client.init();

KOptions requestOptions = new KOptions();
requestOptions.add(PkinitOption.USE_PKINIT);
requestOptions.add(PkinitOption.USING_RSA);
requestOptions.add(KrbOption.CLIENT_PRINCIPAL, principal);

if (APPROACH_ONE) {
// cert and key load ok (are not null), but seem to be ignored
Certificate certificate = readCertificateFile(pemFile);
requestOptions.add(PkinitOption.X509_CERTIFICATE, certificate);

PrivateKey privateKey = readPrivateKeyFile(keyFile);
requestOptions.add(PkinitOption.X509_PRIVATE_KEY, privateKey);
} else {
// identity string set to “/path/to/pem,/path/to/pkcs8key"
requestOptions.add(PkinitOption.X509_IDENTITY, pathTo(pemFile) 
+ "," + pathTo(keyFile));
}

TgtTicket tgt = client.requestTgt(requestOptions);



but the server keeps complaining that “received_cert is null”, which I assume 
means the user cert is not being included in the request. Can anyone tell me if 
either (1) what I want to do isn’t really implemented yet, or (2) I am missing 
something.

Thanks
 - Lloyd

RE: [jira] [Updated] (DIRKRB-532) Encode and decode XDR: Union and Struct

[Zheng, Kai]

Note the whole kadmin-remote branch would be better to target on a release 
after RC2.

-Original Message-
From: Kai Zheng (JIRA) [mailto:j...@apache.org] 
Sent: Friday, February 19, 2016 3:52 PM
To: dev@directory.apache.org
Subject: [jira] [Updated] (DIRKRB-532) Encode and decode XDR: Union and Struct


 [ 
https://issues.apache.org/jira/browse/DIRKRB-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kai Zheng updated DIRKRB-532:
-
Fix Version/s: (was: 1.0.0-RC2)
   1.0.0-GA

> Encode and decode XDR: Union and Struct
> ---
>
> Key: DIRKRB-532
> URL: https://issues.apache.org/jira/browse/DIRKRB-532
> Project: Directory Kerberos
>  Issue Type: Task
>Affects Versions: 1.0.0-RC2
>Reporter: YanYan
>Assignee: YanYan
> Fix For: 1.0.0-GA
>
> Attachments: DIRKRB-532-v1.patch
>
>
> To continue the work of {{XDR}}, we should implement {{XDR-Union}} and 
> {{XDR-StructType}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: Cursor to implement Closeable

[Zheng, Kai]

Thanks Radovan for the interesting illustration. I guess I understand it but am 
not so sure. So application exception is passed to close(exception) method, 
then in the implementation of the close method, will it throw the given 
exception? If it does, how about it timed out?

Regards,
Kai

-Original Message-
From: Radovan Semancik [mailto:radovan.seman...@evolveum.com] 
Sent: Tuesday, February 02, 2016 6:21 PM
To: dev@directory.apache.org
Subject: Re: Cursor to implement Closeable

On 01/30/2016 12:33 PM, Zheng, Kai wrote:
> Not sure if it's a good practice to pass an exception as reason to a close 
> method, as least in Java.
> Confusing: exception thrown when this Cursor is accessed after close. When 
> it's accessed after close, why call the method once more?

Actually (as far as I know) there is no good way to do that in Java. No good 
way at all.

Imagine that you implement a "driver" where LDAP is just one of many ways how 
to access the data. You do LDAP search in the driver and one of the entry has 
an application error. You want to throw an exception that indicates that 
condition, but you also have end the search and close the connection. And now 
imagine that there is a network timeout on close. 
Which exception do you throw?

The typical implementation seems to be throwing the application exception and 
ignoring the IO exceptions from close(). But that may end up in resource 
leakage, because if it is a timeout then the cursor might or might not be 
closed. If the client code does not handle that properly then unclosed cursors 
may stay around for a long time.

On the other hand, throwing the IO exception and ignoring application 
exceptions may be even worse, because it suggests that a retryable network 
error while the root cause of the problem may be non-retryable and it may be so 
serious that re-trying the operation may cause serious harm.

So, throwing both exception as nested may in fact be a good compromise.

--
Radovan Semancik
Software Architect
evolveum.com

RE: Cursor to implement Closeable

[Zheng, Kai]

The proposed change makes sense to me. Then in new Java style, codes can be 
like: try (Cursor c = Cursor.open(xxx)) {}.

But I don't know what close(Exception) method is for. Looks to me, close() 
throws IOException is enough.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Saturday, January 30, 2016 4:21 PM
To: Apache Directory Developers List 
Subject: Cursor to implement Closeable

Hi guys,

as suggested by Maxim, I have changed teh code so that our Cursor interface now 
extends Closeable. It has some kind of huge impact on all our code, although it 
was not really a burden to take car of that. I know have changed teh API and 
ApacheDS. Studio has to be changed too (I'll do that this week-end).

The main impact is that the close() and close(Exception) methdos now throw 
IoException, so it hs to be caught where those methods are called.
That's pretty much it.

RE: Cursor to implement Closeable

[Zheng, Kai]

Got it, thanks. 

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Saturday, January 30, 2016 7:48 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Cursor to implement Closeable

Le 30/01/16 12:33, Zheng, Kai a écrit :
> Just did a search getting below. I thought it's the method we're talking 
> about.
> 
> void close(Exception reason)
>
> Closes this Cursor and frees any resources it my have allocated. Repeated 
> calls to this method after this Cursor has already been called should not 
> fail with exceptions. The reason argument is the Exception instance thrown 
> instead of the standard CursorClosedException.
>
> Parameters:
> reason - exception thrown when this Cursor is accessed after close 
> 
>
> Not sure if it's a good practice to pass an exception as reason to a close 
> method, as least in Java.

The Javadoc is far from being clear. let me expose a bit of code where the 
usage is clearer :

public boolean next() throws LdapException, CursorException
{
if ( done )
{
return false;
}

try
{
if ( future.isCancelled() )
{
response = null;
done = true;
return false;
}

response = future.get( timeout, timeUnit );
}
catch ( Exception e )
{
LdapException ldapException = new LdapException( 
LdapNetworkConnection.NO_RESPONSE_ERROR, e );

// Send an abandon request
if ( !future.isCancelled() )
{
future.cancel( true );
}

// close the cursor
try
{
close( ldapException );
}

Typiclaly, here, we have had no response to a future.get() call, and we should 
then close the cursor. Calling close() would not provide any information to the 
monitor that is used internally to store this information. It allows the 
application using the Future to know what has hapepned.

RE: Database corruption repair tool

[Zheng, Kai]

>> I'm most certainly overdoing : the first step is to start the server, which 
>> is all but a good idea. I have to simply read the configuration instead, 
>> because this is all what I need.

You mean it doesn't have to use or start a server to run the repair process, 
right. If so it sounds good, because purely running a repair tool against the 
database would be easy to use. Later it can also be a healthy check tool.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, January 29, 2016 3:41 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Database corruption repair tool

Le 29/01/16 07:41, Zheng, Kai a écrit :
> Thanks for the great work, Emmanuel.
>
> I have some questions. As discussed previously, it's hard to recreate the 
> database corrupt issue. Did you include a test with a sample corrupt database 
> image and show if it's can be repaired? All the work in a unit test or 
> integration test. Does the repair process just read the database image 
> without any updating or writing? Sorry I don't get the chance to understand 
> the work in details, and it's possible you have done that already. If so 
> please ignore my concerns. Thanks.
Note that atm, it works in a unit test, but when run outside, I'm facing 
issues. I'm most certainly overdoing : the first step is to start the server, 
which is all but a good idea. I have to simply read the configuration instead, 
because this is all what I need.

I'll most certtainly will come with a lighter version this week-end.

RE: Database corruption repair tool

[Zheng, Kai]

>> The assumption is that the MasterTable is not corrupted ...
Ah, got it. So the repair tool is more like a index recreating tool. Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, January 29, 2016 3:40 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Database corruption repair tool

Le 29/01/16 07:41, Zheng, Kai a écrit :
> Thanks for the great work, Emmanuel.
>
> I have some questions. As discussed previously, it's hard to recreate the 
> database corrupt issue. Did you include a test with a sample corrupt database 
> image and show if it's can be repaired? 
There is no need of a corrupted database to test it. The assumption is that the 
MasterTable is not corrupted (because if it is, we are dead in the water...). 
Based on this assumption, we simply delete all the existing indexes, and 
recreate them from scratch.

Testing it is just a matter of creating a database, run the repair tool on it, 
and check that all the resulting content is correct. This is what the unit test 
is doing.

RE: Database corruption repair tool

[Zheng, Kai]

I see. Thanks for the details. Talk is easy, it's still depending on the codes 
and the real work. 

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, January 29, 2016 11:11 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Database corruption repair tool

Le 29/01/16 15:51, Zheng, Kai a écrit :
>>> I'm most certainly overdoing : the first step is to start the server, which 
>>> is all but a good idea. I have to simply read the configuration instead, 
>>> because this is all what I need.
> You mean it doesn't have to use or start a server to run the repair process, 
> right. 

Right. We just need to know where to find the data, and which index are to be 
recreated. This is described in the configuration partition. We also have to 
know about the schema, thus be able to read it.

> If so it sounds good, because purely running a repair tool against the 
> database would be easy to use. Later it can also be a healthy check tool.

Ideally, we should be able to start the server in repair mode. This is what we 
do when we define a new index : you don't have to create the index files, it's 
done at startup (actually, this is automatic, we see that an index table is 
missing, and we create it).

That makes me thing that a repair mode would be much simpler than starting the 
server with a 'repair' parameter : it's enough to delete all the indexes, they 
will be recreated at startup !!! (Actually, t won't work simply because we 
recreate the user index, not the system indexes, but the idea is brillant : we 
just have to check the system index and rebuild them if missing... I'll do that 
this week-end !)

Thanks Kai : you again proved that discussing a pb is the best way to see a 
better way to deal with it :-)

RE: [Fortress]Developers List

[Zheng, Kai]

Like Kerby, I agree for the moment it may be good to use the same mailing list 
for Fortress for all the Fortress specific discussions.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, January 28, 2016 11:40 PM
To: Apache Directory Developers List 
Subject: Re: [Fortress]Developers List

Le 28/01/16 15:11, Shawn McKinney a écrit :
> Fellow Dev's,
>
> We’ve just added a new committer to fortress, and my goal is to add a few 
> more before long.  My question is which list to use for communicating?  In 
> the past, with our limited discussions, we’ve used the fortress list.  But 
> that list is (supposed to be) for users.  We could use the directory dev 
> list, with fortress label added to the subject line.  But I’m wondering if it 
> is time to add a list specific to fortress dev topics.

At the moment, I think 'users' are most certainly likely to become 
'developpers' at some point. Making a distinction is probably a bit premature.

Wehn the number of users will grow up to a point the mailing list starts to be 
flooded by beginners questions, then we can decide to create a dedicated 
fortress-dev mailing list.

Also it's good for developpers to deal with user's questions, and for users to 
feel like included into developers discussions.

my 2 cts.

RE: Database corruption repair tool

[Zheng, Kai]

Thanks for the great work, Emmanuel.

I have some questions. As discussed previously, it's hard to recreate the 
database corrupt issue. Did you include a test with a sample corrupt database 
image and show if it's can be repaired? All the work in a unit test or 
integration test. Does the repair process just read the database image without 
any updating or writing? Sorry I don't get the chance to understand the work in 
details, and it's possible you have done that already. If so please ignore my 
concerns. Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, January 28, 2016 8:02 AM
To: Apache Directory Developers List 
Subject: Re: Database corruption repair tool

Le 27/01/16 23:33, Emmanuel Lécharny a écrit :
> Hi guys,
>
> as I said, I was working on porting Kiran's partition-plumber in 
> ApacheDS. It's now done, and tested (minimally, I must say...).
>
> I have created some packages that contain this feature, available on 
> people.apache.org/~elecharny. It's not official, but as soon as we 
> have a proof that it works, we will cut a release containing this feature.
>
> There is an added option that you can use when starting the server :
> 'repair'. Launching 'apacheds.sh repair' should do the trick. I 
> *think* I have also handled the wrapper, but that has to be tested. 
> Same thing for windows script.
>
> You can give it a try !
Obviously, it's not perfect :/ There is some needed work on the wrapper, and 
the logs.

i'll try to get a new version out tomorrow evening.

RE: About project site

[Zheng, Kai]

Thanks Emmanuel for the details!

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, January 29, 2016 2:10 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: About project site

Le 29/01/16 03:18, Zheng, Kai a écrit :
> I don't know the mentioned "CMS plugin" either. Would anyone give a hint? 
> Thanks.

The CMS system in use at Apache works in two phases :
- first you commit your updates into SVN/git, and it is published on a staging 
site. You can control the rendering before it gets visible to the world.
- then when you are happy with the result, you can publish it on the production 
site, using a browser plugin

The description is on http://www.apache.org/dev/cmsref.html

Actually, it's not a plugin but a bookmarklet. This page
(https://cms.apache.org/#bookmark) explains how to install it (at the
bottom) :

"Please be sure to install the bookmarklet on your browser toolbar by either 
dragging and dropping the ASF CMS 
<javascript:void(location.href='https://cms.apache.org/redirect?uri='+escape(location.href))>
link to your toolbar or by creating a new bookmark by either right-clicking on 
that link and selecting "Bookmark this Link", or by opening a "New Bookmark" 
dialog screen from your browser's menu and typing the following into the 
Location/URL field:

javascript:void(location.href='https://cms.apache.org/redirect?uri='+escape(location.href))"

This link allows you to browse the staging site edit it from the browser, and 
more important, to publish it. (I actually never edited the staging site from 
the browser : the UI is way to crude ;-)

RE: About project site

[Zheng, Kai]

I don't know the mentioned "CMS plugin" either. Would anyone give a hint? 
Thanks.

Regards,
Kai

-Original Message-
From: Li, Jiajia [mailto:jiajia...@intel.com] 
Sent: Thursday, January 28, 2016 4:13 PM
To: ke...@directory.apache.org
Subject: RE: About project site



-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, January 28, 2016 3:50 PM
To: ke...@directory.apache.org
Subject: Re: About project site

Le 28/01/16 08:00, Li, Jiajia a écrit :
> Yes, if no one push or review until tomorrow morning, I will push it.

have you setup teh CMS plugin in your browser ?

no, and I'm sorry that I don't know the "CMS plugin" used for what?

RE: JdbmPartition repair

[Zheng, Kai]

>> If we are to do that one day, we would rather use LMDB, which is way faster 
>> than SqlLite, proven, and small.

Agree. Looking at the benchmark result http://symas.com/mdb/microbench/, LMDB 
seems pretty good as well as LevelDB. One question, is it license (the OpenLDAP 
public license) compatible with ASF 2.0? 

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, January 25, 2016 11:58 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: JdbmPartition repair

Le 25/01/16 15:27, Zheng, Kai a écrit :
> Thanks a lot for the detailed and insightful explanation. I'm not able to 
> absorb it well because not familiar with the codes. It will serve as very 
> good materials when someday I need to look into the LDAP things. The details 
> make me believe it's very necessary to have a strong, mature, industry proven 
> backend for the LDAP server because the LDAP things are already kinds of 
> complex enough. We can't combine the LDAP logic with the storage engine, they 
> need to be separated, developed and tested separately. Looks like Mavibot is 
> going in this way and sounds good to me. What concerned me is that as we're 
> lacking enough resources on developing it, it may still take some time to 
> become mature and robust. 
Mavibot code base is small : 17 947 SLOCS


> But if we leverage some existing engine, then we can focus on the LDAP 
> stuffs and work on some advanced features, move on a little faster and 
> have releases like 2.x, 3.x and so on. Sqlite yes is C, but it's 
> supported on many platforms and Java can use it via JNI;
That would be a real pain. Linking som JNDI lib and make it a package is really 
something we would like to avoid like plague.

If we are to do that one day, we would rather use LMDB, which is way faster 
than SqlLite, proven, and small.

> it's a library, can be embedded in an application. You may dislike 
> JNI, but only a few of APIs are going to be wrapped for the usage, and 
> actually there're already wonderful wrappers for Java. Like 
> SnappyJava, the JNI layer along with the library can be bundled within 
> a jar file and get distributed exactly as a maven module. One thing 
> I'm not sure is how well the LDAP entries fit with the sql table 
> model,
Bottom line : very badly. Actually, using a SQL backend to store LDAP element 
is probably the worst possible solution. Simply because LDAP support 
multi-valued entries, something SAL databases don't support antively.

> but I guess there could be pretty much investigations in this direction. The 
> benefit would be, saving us amounts of developing and debugging time, robust 
> and high performance, transaction support and easy query. Some thoughts in 
> case any helps. Thanks.

Thanks. We have been evaluation all thos options for more than a decade now :-) 
OpenLDAP has gone the exact same path, for the exact same reasons.

RE: JdbmPartition repair

[Zheng, Kai]

Thanks a lot for the detailed and insightful explanation. I'm not able to 
absorb it well because not familiar with the codes. It will serve as very good 
materials when someday I need to look into the LDAP things. The details make me 
believe it's very necessary to have a strong, mature, industry proven backend 
for the LDAP server because the LDAP things are already kinds of complex 
enough. We can't combine the LDAP logic with the storage engine, they need to 
be separated, developed and tested separately. Looks like Mavibot is going in 
this way and sounds good to me. What concerned me is that as we're lacking 
enough resources on developing it, it may still take some time to become mature 
and robust. But if we leverage some existing engine, then we can focus on the 
LDAP stuffs and work on some advanced features, move on a little faster and 
have releases like 2.x, 3.x and so on. Sqlite yes is C, but it's supported on 
many platforms and Java can use it via JNI; it's a library, can be embedded in 
an application. You may dislike JNI, but only a few of APIs are going to be 
wrapped for the usage, and actually there're already wonderful wrappers for 
Java. Like SnappyJava, the JNI layer along with the library can be bundled 
within a jar file and get distributed exactly as a maven module. One thing I'm 
not sure is how well the LDAP entries fit with the sql table model, but I guess 
there could be pretty much investigations in this direction. The benefit would 
be, saving us amounts of developing and debugging time, robust and high 
performance, transaction support and easy query. Some thoughts in case any 
helps. Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, January 25, 2016 1:32 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: JdbmPartition repair

Le 24/01/16 16:47, Zheng, Kai a écrit :
> Thanks Emmanuel for the sync and sharing. The approach looks pretty good, and 
> is often seen in many mature products. The repair process is triggered when 
> corruption is found while the server is running, or while restarting with a 
> specific option? Or the both? If the repairing stuff is not easy to 
> integrate, maybe a repair tool like the one Kiran worked out sounds good to 
> use? Or during startup time checking the data/index, if not fine then Java 
> system launching the tool process for the fixing? Just some thoughts, in case 
> some useful.

The corruption happens in some rare cases, and it's mostly due to some 
concurrent updates. Let me explain what happens in detail, and sorry of it's a 
big lengthly, it has to be.

We store entries in what we call the MasterTable. Entries are serialized, and 
each one of them has an associated ID (actually, we are using random UUID). So 
the master table is containing tuples of <UUID,
Entry>.
Each index refers to this MasterTable using the entry UUID. Typically, let's 
say an entry has an ObjectClass person, then the ObjectClass index will have a 
tuple <ObjectClass, Set> wher ethe set contains all the Entry's UUID of 
entrues that has the 'person' ObjectClass.

We also have one special index, the Rdn index. This one is more complex, 
because it is used for two things : refering to an entry from a RDN, and also 
keep a track of the hierarchy. If we have an entry which DN is 
ou=users,dc=example,dc=com, where dc=exmple,dc=com is the partition's root, 
then the RDN index will contain two tuples for the full DN : one for the entry 
itself, and one for the suffix. Actually, we don't store tuples like <Rdn, ID>, 
but a more complex structure, the ParentIdAndRdn.
The reason is that we may have many entries using the same RDN. For instance :

entry 1 : cn=jSmith,ou=users,dc=example,dc=com
entry 2 : cn=jSmith,ou=administrators,dc=example,dc=com

That this jSmith is one person or two is irrelevant. The thing is that we can't 
associate the RDN cn=jSmith with one single entry, so what we store is a tuple 
<entryId1, 

RE: JdbmPartition repair

[Zheng, Kai]

Thanks Emmanuel for the sync and sharing. The approach looks pretty good, and 
is often seen in many mature products. The repair process is triggered when 
corruption is found while the server is running, or while restarting with a 
specific option? Or the both? If the repairing stuff is not easy to integrate, 
maybe a repair tool like the one Kiran worked out sounds good to use? Or during 
startup time checking the data/index, if not fine then Java system launching 
the tool process for the fixing? Just some thoughts, in case some useful.

I'm not very sure to rewrite JDBM though I know there're plenty of reasons to 
do so, as most software rewritings do. But if we have start with new, 
implementing something like B+ tree, that needs transaction support, I'm 
wondering if we could do it by leveraging already industry proven backend, 
because developing such backend may take long time effort and pretty much of 
resources. I'm wondering if Sqlite could serve the purpose well or not, or how 
it can be wrapped or adapted for the usage here. Again just a quick thought and 
in case somewhat useful.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Sunday, January 24, 2016 9:40 PM
To: Apache Directory Developers List 
Subject: JdbmPartition repair

Hi guys,

we have many users complaining about a corrupted JDBM database. As of today, we 
don't have another solution than telling them to reload their data, which is 
all be comfortable. First because it might take ages (reloading data is very 
slow) and also because they might not have a backup.

Although this is not a frequent scenario, when it happens, it really take down 
any credibility ApacheDS can have.

Here, we all know that Mavibot will be the solution, but until it's available 
with transaction support, we have to propose a tool that restore - of possible 
- the database.

Hopefully, Kiran has worked on a tool that does that : the partition-plumber. 
The idea is to intergrate this tool into ApacheDS in order to allow users to 
restore their database in  a simple way. Here is what I propose :

- first, a way to start ApacheDS in a repair mode. That will drip all the 
indexes, and recreate them based on the master table. It might take some time, 
but it will be way better than any solution, and in any case, will be faster 
than a full reload, consider that we will bypass many checks. I suggest an 
option : apacheds -repair. When the server is started with that option, the 
server will restart after having cleaned up the database
- the way to implement it is to add a method in the Partition interface
: repair(). Not all the partition will need it, so only JdbmPartition will 
actually iumplement it.
- that method will simply delete (or copy, if we want a backup) all the 
existing indexes (system and users). We then will recreate the indexes based on 
the master table content. There is still a remote risk that the master table 
can be corrupted, but it's unlikely, or at least very rare.
Actually, the Rdn index is the one which get corrupted most of the time, 
because it get updated many times for each addition, move, rename or delete 
operations.

I'm currently working on that, and it should be done fast enough (say, in less 
than a week, or even quicker if I have enough time this sundy and at night).

The next step, and I'm also working on that, is to finish Mavibot. The problem 
is that it's a complex piece of code, and it's hard to work on it when I just 
have a couple of hours on evening or during the week-end.
I'm sorry for that. But we eventually will get it ready !


Thanks !

RE: Package creation for Canonical PPA ?

[Zheng, Kai]

Sounds great. I agree.

Regards,
Kai

From: Ole Ersoy [mailto:ole.er...@gmail.com]
Sent: Thursday, January 21, 2016 10:01 PM
To: Apache Directory Developers List 
Subject: Re: Package creation for Canonical PPA ?

There's already various docker containers running ADS:
https://hub.docker.com/r/h3nrik/apacheds/

In most cases I think this is better than a PPA.

Cheers,
Ole

On 01/21/2016 04:26 AM, Kiran Ayyagari wrote:


On Thu, Jan 21, 2016 at 3:39 PM, Emmanuel Lécharny 
> wrote:
Hi guys,

one person asked if we were to create a PPA package for Ubuntu. FTR (I
had no idea what it was), a PPA is a Personal Package Archive
(https://help.launchpad.net/Packaging/PPA), so basically, a repository
that you can create and that wll contain your own packages. It may be
useful in a company that develops their own packages, when they want to
make them available to all their computers.

IMHO, it seems totally overkilling, unless someone wants to take care of
it and maintain it (I won't). And there is a coraletral problem : how
will we manage to setup a correct version of Java if we provide an
ApacheDS package ?
this is the blocker when I tried to work on a PPA sometime ago, Oracle Java
is not available in the public repos and we have never tested the server
with IcedTea and OpenJDK.

Thoughts ?

RE: MIA for 10 days

[Zheng, Kai]

Hi Emmanuel,

Please enjoy and have a wonderful vacation! Will miss you very much for some 
discussions. :)

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Tuesday, January 12, 2016 3:25 PM
To: Apache Directory Developers List ; dev 
; ke...@directory.apache.org
Subject: MIA for 10 days

Hi guys !

I'll be MIA for 10 days, with no internet connection - and more important : no 
computer ! -. Vacations ! (I'm going to visit the south of Germany, and its 
crazy castles. Sorry Stefan, we won't stop in München this time :/)

Have fun in the mean time and see you in 10 days !

Emmanuel

RE: Happy New Year !

[Zheng, Kai]

Ah, happy new year and the great holiday has just passed. Wish the projects all 
develop and evolve well in this new future!

Thanks all for the great support in the past year.

Regards,
Kai

-Original Message-
From: Shawn McKinney [mailto:smckin...@apache.org] 
Sent: Saturday, January 02, 2016 12:42 AM
To: Apache Directory Developers List 
Cc: ke...@directory.apache.org
Subject: Re: Happy New Year !

Back at you Emmanuel!  It feels like an exciting time to be a part of these 
Apache Directory projects.

May you all have a lasting positive impact within your respective teams and 
enjoy peace and prosperity in the coming year.

Best

Shawn

> On Jan 1, 2016, at 2:43 AM, Emmanuel Lécharny  wrote:
> 
> 2016 is still in its infancy, but it will grow fast !
> 
> I wish all of you an excellent year full or releasse and not too many 
> bugs ;-)
> 
> Emmanuel

RE: Reconsider how to layout kerby-pkix

[Zheng, Kai]

Kindly let me resend this to directory list for broader feedbacks if any. 
Thanks.

-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Wednesday, December 30, 2015 7:53 PM
To: ke...@directory.apache.org
Subject: Reconsider how to layout kerby-pkix

Hi folks,

I'm reconsidering how to layout kerby-pkix because sooner or later we will put 
more codes into it while implementing PKINIT fully particularly in the RSA 
case. Eventually we'll get rid of the codes from commons-ssl project and 
implement our own for the lacked facilities. We'll also try to avoid relying on 
JRE in the field because we have our own CMS/X509 codes already (CMS not 
available in JRE) thus we don't want to spend much time to convert back and 
forth among types from different side. So considering that, we may not want the 
module become too large in future, and if it has to split then I guess it's 
better to split it right now, before the release. Below is the layout I propose 
to use:
Kerby-pkix
-pkix-cms
-pkix-x509
-pkix-pkcs (pkcs8, pkcs12 and etc., now commons-ssl fits here but 
to be removed out later when not needed any longer)

In the each child module, the defined types are to be there along with relevant 
logics, algorithms, and supports related to the types.
One thing to worry about is their relationship or dependencies among these 
children. It looks rather messy in related specs to me, so any insight here?
The kerby-pkix library will stand alone only relying on kerby-asn1 library, not 
relying on any Kerberos things. Surely kerby-kerb will use it for the PKINIT 
support.

In future, the resultant kerby-pkix module will serve a complete and standalone 
library like kerby-kerb and can be used for the PKIX things. People may think 
this is out of the Kerberos scope, but I would think it's not. Kerby bases it 
on the Kerberos foundation, but would also support and integrate other 
authentication mechanisms like token and PKINIT. Purely Kerberos support may 
not let Kerby go far, IMO.

Thoughts and suggestions are very welcome! Thanks.

Regards,
Kai

RE: [kerby] ASN1 Quick review

[Zheng, Kai]

While before someone may find and complain (I like it actually) about it, I'd 
like to mention that Javadoc is another thing we need to complement. I will add 
comments and Javadoc in the API and critical places once the code base is 
stabilized after some left issues are cleared.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, December 24, 2015 1:29 AM
To: Apache Directory Developers List 
Subject: Re: [kerby] ASN1 Quick review

Some more questions, now that I have drawn the full Asn1 hierarchy
(http://pasteboard.co/fGVRQFm.png)

- can't we merge the Asn1Encodable and AbstractAsn1Type classes ?
- same question for the Asn1Cnstructed and Asn1Collection classes
- I'm not sure the Asn1Dumpable interface makes a lot of sense. Why don't we 
simply implement a toString() method that takes an identation as a parameter ?

RE: [kerby] ASN1 Quick review

[Zheng, Kai]

Nice comments! Let me focus on something to explain. 

Regarding merge AbstractAsn1Type and Asn1Encodeable. As I said before, the 
former wraps a Java value, the latter does the encoding/decoding dirty work. 
The separation may does no good so far, but would also do no hurt for the left. 
Something may start with the latter and doesn't like the generic thing. How 
about if we make the parser results encodeable/decodeable? On other Java 
platform that doesn't support the generic thing very well? How about if we 
bridge this library to other ASN1 stuffs? Yes as you said these are just maybe, 
uncertain things. But if the merging doesn't generate some good for now, I 
thought it may be not bad to go the way.

I guess you're mentioning two approaches: either let the ASN1 objects do 
encode/decode themselves, or have some help class to delegate the dirty work 
out. Yeah this is an architecture decision that's done when coming up the first 
piece of the codes. I remembered I tried many times, but never got a way that 
works perfect in every aspect. We used the former approach that goes not bad so 
far if we don't attempt to support many other coding rules and do BER/DER as 
good as possible. But if we would do, then we may want to simplify the ASN1 
objects and need to delegate the encoding/decoding things out to helper/facet 
classes. I don't investigate the latter direction very much, to be frankly. One 
thing in mind would be, let the library be driven by our applications. If it's 
required and needs to solve some new cases, then evolve the library to get the 
new cases done elegantly. I would admit that developing the library itself is 
much a burden for us because our limited effort should be focused on Kerberos 
specific, but as you see, we've spent very much time on this, though I believe 
it's worth because it can make Kerberos side easier with it.

Yeah Asn1Specifix should be Asn1Specific, good catch. Currently it's very 
simple and doesn't do much work. Will see if any further cases that require it 
to do more work. A reason for this is, the systems so far using the library are 
majorly type/model driven encoding/decoding from top to bottom, which makes the 
library behave very differently from others. The major work for 
application/context specific types are already handled elsewhere. We need it 
for Asn1.decodeAndDump() call.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, December 24, 2015 5:03 PM
To: ke...@directory.apache.org
Subject: Re: [kerby] ASN1 Quick review

Le 24/12/15 01:56, Zheng, Kai a écrit :
> Nice picture!! My comments are embedded marked as [Kai].
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Thursday, December 24, 2015 1:29 AM
> To: Apache Directory Developers List <dev@directory.apache.org>
> Subject: Re: [kerby] ASN1 Quick review
>
> Some more questions, now that I have drawn the full Asn1 hierarchy
> (http://pasteboard.co/fGVRQFm.png)
> [Kai] Thanks a lot. Very cool! Could we integrate it in the library doc?

Of course !

Find the attached graphml file (the source from which I generated the picture, 
using yEd - https://www.yworks.com/products/yed)

>
> - can't we merge the Asn1Encodable and AbstractAsn1Type classes ?
> [Kai] I guess we can, actually before AbstractAsn1Type is very large. I would 
> prefer to separate them becaue the roles of them are clearly different. 
Separation of concern is actually better done with Interfaces.

> Asn1Encodable is responsible for all the encoding/decoding dirty works; and 
> AbstractAsn1Type would wrap a Java type value using Java generic. 
The real question here is more or less an architctural question. Let's consider 
that an object might have to support multiple 'facets' (as in
http://i.cs.hku.hk/~clwang/projects/facet.html)
- should we let a Class implement a 'facet' ?
- or should we delegate this facet to an helper class ?

For encodable, I would rather think that the help class approach would be way 
too complex, as each ASN1 class has its own implementation of some of teh 
Asn1Encodable classes. This make me think that the first approach is better.

Now, as all the Asn1 classes that extend AbstractAsn1Type already have their 
own implementations of methods like encodingLength(), I'd rather see the 
AbstractAsn1Type abstract class implement what is currently in the 
Asn1Encodable class, and make Asn1Encodable an Interface (becaise the other 
branch of Asn1Object aren't implementing it).

> For now all Asn1Type object are AbstractAsn1Type, but may be not in the 
> future, because there are possible situations where some types don't want to 
> start with AbstractAsn1Type using the generic things. 

DO you have some types in mind ? Or is this just a door you want to maintain 
open, just in case ?

> I wish the library could evolve further so be able to 

RE: [kerby] ASN1 Quick review

[Zheng, Kai]

Nice picture!! My comments are embedded marked as [Kai].

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Thursday, December 24, 2015 1:29 AM
To: Apache Directory Developers List 
Subject: Re: [kerby] ASN1 Quick review

Some more questions, now that I have drawn the full Asn1 hierarchy
(http://pasteboard.co/fGVRQFm.png)
[Kai] Thanks a lot. Very cool! Could we integrate it in the library doc?

- can't we merge the Asn1Encodable and AbstractAsn1Type classes ?
[Kai] I guess we can, actually before AbstractAsn1Type is very large. I would 
prefer to separate them becaue the roles of them are clearly different. 
Asn1Encodable is responsible for all the encoding/decoding dirty works; and 
AbstractAsn1Type would wrap a Java type value using Java generic. For now all 
Asn1Type object are AbstractAsn1Type, but may be not in the future, because 
there are possible situations where some types don't want to start with 
AbstractAsn1Type using the generic things. I wish the library could evolve 
further so be able to standalone as a complete solution some day.

- same question for the Asn1Cnstructed and Asn1Collection classes
[Kai] Again they were together before but separated out recently. 
Asn1Collection is purely for set/setoff/sequence/sequenceof. Asn1Constructed 
can be another case where primitive type but using constructed encoding. You 
could check the places where it's used. An example in Asn1Converter.

- I'm not sure the Asn1Dumpable interface makes a lot of sense. Why don't we 
simply implement a toString() method that takes an identation as a parameter ?
[Kai] Right initially when implementing the dump support we went the way, we 
used a separate method toStr() but found it doesn't work nicely. toString() 
with a indent parameter looks anti-intuitive I guess. A dumpable can be passed 
a dumper as well and using the dumper it can share the same underlying String 
builder along with all kinds of utility functions. Note only complex and bridge 
types like Asn1CollecionType, Asn1Any and Asn1Container need to go the way, 
simple types use Java toString() naturally. 

I thought the dumping support is very important because without it, many time 
it's very hard, time-consuming, and frustrating when digging into a large 
hierarchy structure or more than 1k bytes for a bug. It's surely a place we can 
further improve.

Regards,
Kai

RE: [kerby] ASN1 Quick review

[Zheng, Kai]

Thanks Emmanuel for the review and great comments! The questions are hard but 
fortunately I'm still kept in the loop so my pleasure to address them. My 
comments are embedded and marked by [Kai].

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Wednesday, December 23, 2015 8:54 PM
To: Apache Directory Developers List 
Subject: [kerby] ASN1 Quick review

Hi band,

I'm having a quick look at the kerby-asn1 code, as I wanted to paly around the 
idea of porting the LDAP codec to use this piece of nice code. AFAIU, when you 
want to declare an object that can be encoded or decoded, you have to extend 
the correct Asn1Object child. Looking at the Ticket object, here is what I see :

[Kai] Glad you want a try. This is also something I wish to help with as 
discussed before, but am not able to do it immediately because of bandwidth. 
Sorry for that. I certainly would and will also be able to try to provide any 
help if needed.

...
import static org.apache.kerby.kerberos.kerb.type.ticket.Ticket.MyEnum.*;
...
public class Ticket extends KrbAppSequenceType {
public static final int TKT_KVNO = KrbConstant.KRB_V5;
public static final int TAG = 1;

protected enum MyEnum implements EnumType {
TKT_VNO,
REALM,
SNAME,
ENC_PART;

@Override
public int getValue() {
return ordinal();
}

@Override
public String getName() {
return name();
}
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[] {
new ExplicitField(TKT_VNO, 0, Asn1Integer.class),
new ExplicitField(REALM, 1, KerberosString.class),
new ExplicitField(SNAME, 2, PrincipalName.class),
new ExplicitField(ENC_PART, 3, EncryptedData.class)
};

I like the idea of defining the fields this way, except that I would suggest 
some slight modifications :

- get read of the import ...Ticket.MyEnum.*;
[Kai] Hmmm, I guess you mean "get rid of", good point. It's like this because, 
initially we didn't use enum, but int constants. And some weeks ago when we 
want to dump user defined type objects like this with meaningful field info, we 
switched to use enum because it can give a friendly name. We were in a hurry at 
that time and wanted to do it as less effort as possible, thus it's like this 
now: the enum constant is rather like int constant and used as before.

- make the enum private (there is no reason we wuld like to expose it anyway)
[Kai] Well, actually there are some reasons to make it protected and 
disciplined exposed. Such user defined types can be extended and these fields 
may be accessed there. Ref. child classes of ContentInfo (also some other 
examples I remembered when defining protected int constants).

- name it something more meaningful, like TicketField inseatd if MyEnum
[Kai] Right agree. Again it was like this because it's out as a simple pattern 
in a whole project scope replacement.

- use it with the enum name, like in new ExplicitField(TicketField.TKT_VNO, 0, 
Asn1Integer.class)
[Kai] Agree.


I find the "import static xxx.*;" atrocious, most of the time. It makes it 
barely readable : you have to go to the top of your file to actually
*know* where the constant comes from... That may seems of for small files, but 
otherwise... I accept it for Asserts, because it's really clear, in a test 
context - pretty much like annotations.

[Kai] I thought you may be right, but ...

Here is what I come with :

public class Ticket extends KrbAppSequenceType {
public static final int TKT_KVNO = KrbConstant.KRB_V5;
public static final int TAG = 1;

private enum TicketField implements EnumType {
TKT_VNO,
REALM,
SNAME,
ENC_PART;

@Override
public int getValue() {
return ordinal();
}

@Override
public String getName() {
return name();
}
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[] {
new ExplicitField(TicketField.TKT_VNO, 0, Asn1Integer.class),
new ExplicitField(TicketField.REALM, 1, KerberosString.class),
new ExplicitField(TicketField.SNAME, 2, PrincipalName.class),
new ExplicitField(TicketField.ENC_PART, 3, EncryptedData.class)
};

(note that it's just a suggestion at this point...)
[Kai] They're very good suggestions and should become true, though a tiresome 
work because there are so many user defined types now. I'm wondering if any 
contributor would help with such. 

Now, let's foduc on the fields declarations. Here, we create ExplicitFields, 
passing a Xxx.class as the third parameter, and a number as the second 
parameter.

First of all, as the enum being used has an implicit ordering, can't we simply 
avoid passing those numbers ? There is already an ExplicitField constructor 
that takes only 2 parameters, deducing the number from teh 

RE: [kerby] ASN1 Quick review

[Zheng, Kai]

Resend after formatted.

Thanks Emmanuel for the review and great comments! The questions are hard but 
fortunately I'm still kept in the loop so my pleasure to address them. My 
comments are embedded and marked by [Kai].

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Wednesday, December 23, 2015 8:54 PM
To: Apache Directory Developers List 
Subject: [kerby] ASN1 Quick review

Hi band,

I'm having a quick look at the kerby-asn1 code, as I wanted to paly around the 
idea of porting the LDAP codec to use this piece of nice code. AFAIU, when you 
want to declare an object that can be encoded or decoded, you have to extend 
the correct Asn1Object child. Looking at the Ticket object, here is what I see :

[Kai] Glad you want a try. This is also something I wish to help with as 
discussed before, but am not able to do it immediately because of bandwidth. 
Sorry for that. I certainly would and will also be able to try to provide any 
help if needed.

...
import static org.apache.kerby.kerberos.kerb.type.ticket.Ticket.MyEnum.*;
...
public class Ticket extends KrbAppSequenceType {
public static final int TKT_KVNO = KrbConstant.KRB_V5;
public static final int TAG = 1;

protected enum MyEnum implements EnumType {
TKT_VNO,
REALM,
SNAME,
ENC_PART;

@Override
public int getValue() {
return ordinal();
}

@Override
public String getName() {
return name();
}
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[] {
new ExplicitField(TKT_VNO, 0, Asn1Integer.class),
new ExplicitField(REALM, 1, KerberosString.class),
new ExplicitField(SNAME, 2, PrincipalName.class),
new ExplicitField(ENC_PART, 3, EncryptedData.class)
};

I like the idea of defining the fields this way, except that I would suggest 
some slight modifications :

- get read of the import ...Ticket.MyEnum.*; 
[Kai] Hmmm, I guess you mean "get rid of", good point. It's like this because, 
initially we didn't use enum, but int constants. And some weeks ago when we 
want to dump user defined type objects like this with meaningful field info, we 
switched to use enum because it can give a friendly name. We were in a hurry at 
that time and wanted to do it as less effort as possible, thus it's like this 
now: the enum constant is rather like int constant and used as before.

- make the enum private (there is no reason we wuld like to expose it anyway) 
[Kai] Well, actually there are some reasons to make it protected and 
disciplined exposed. Such user defined types can be extended and these fields 
may be accessed there. Ref. child classes of ContentInfo (also some other 
examples I remembered when defining protected int constants).

- name it something more meaningful, like TicketField inseatd if MyEnum 
[Kai] Right agree. Again it was like this because it's out as a simple pattern 
in a whole project scope replacement.

- use it with the enum name, like in new ExplicitField(TicketField.TKT_VNO, 0, 
Asn1Integer.class) 
[Kai] Agree.


I find the "import static xxx.*;" atrocious, most of the time. It makes it 
barely readable : you have to go to the top of your file to actually
*know* where the constant comes from... That may seems of for small files, but 
otherwise... I accept it for Asserts, because it's really clear, in a test 
context - pretty much like annotations.

[Kai] I thought you may be right, but ...

Here is what I come with :

public class Ticket extends KrbAppSequenceType {
public static final int TKT_KVNO = KrbConstant.KRB_V5;
public static final int TAG = 1;

private enum TicketField implements EnumType {
TKT_VNO,
REALM,
SNAME,
ENC_PART;

@Override
public int getValue() {
return ordinal();
}

@Override
public String getName() {
return name();
}
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[] {
new ExplicitField(TicketField.TKT_VNO, 0, Asn1Integer.class),
new ExplicitField(TicketField.REALM, 1, KerberosString.class),
new ExplicitField(TicketField.SNAME, 2, PrincipalName.class),
new ExplicitField(TicketField.ENC_PART, 3, EncryptedData.class)
};

(note that it's just a suggestion at this point...) 
[Kai] They're very good suggestions and should become true, though a tiresome 
work because there are so many user defined types now. I'm wondering if any 
contributor would help with such. 

Now, let's foduc on the fields declarations. Here, we create ExplicitFields, 
passing a Xxx.class as the third parameter, and a number as the second 
parameter.

First of all, as the enum being used has an implicit ordering, can't we simply 
avoid passing those numbers ? There is already an ExplicitField constructor 
that takes only 2 parameters, 

RE: [kerby] ASN1 Quick review

[Zheng, Kai]

Thanks Yan for the hard taking! Note it means you would need to manually modify 
200+ classes one by one since we'll need a friendly enum name.

Regards,
Kai

-Original Message-
From: Yan, Yan A [mailto:yan.a@intel.com] 
Sent: Thursday, December 24, 2015 9:13 AM
To: ke...@directory.apache.org; Apache Directory Developers List 
<dev@directory.apache.org>
Subject: RE: [kerby] ASN1 Quick review

Thanks for Emmanuel and Kai's discussion.
I'm wondering if any contributor would help with such.
I'd like to help with the issues, and by the way be familiar with the core part 
codes.

Best regards,
Yan


-Original Message-
From: Zheng, Kai [mailto:kai.zh...@intel.com] 
Sent: Thursday, December 24, 2015 8:31 AM
To: Apache Directory Developers List <dev@directory.apache.org>; 
ke...@directory.apache.org
Subject: RE: [kerby] ASN1 Quick review

Thanks Emmanuel for the review and great comments! The questions are hard but 
fortunately I'm still kept in the loop so my pleasure to address them. My 
comments are embedded and marked by [Kai].

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Wednesday, December 23, 2015 8:54 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: [kerby] ASN1 Quick review

Hi band,

I'm having a quick look at the kerby-asn1 code, as I wanted to paly around the 
idea of porting the LDAP codec to use this piece of nice code. AFAIU, when you 
want to declare an object that can be encoded or decoded, you have to extend 
the correct Asn1Object child. Looking at the Ticket object, here is what I see :

[Kai] Glad you want a try. This is also something I wish to help with as 
discussed before, but am not able to do it immediately because of bandwidth. 
Sorry for that. I certainly would and will also be able to try to provide any 
help if needed.

...
import static org.apache.kerby.kerberos.kerb.type.ticket.Ticket.MyEnum.*;
...
public class Ticket extends KrbAppSequenceType {
public static final int TKT_KVNO = KrbConstant.KRB_V5;
public static final int TAG = 1;

protected enum MyEnum implements EnumType {
TKT_VNO,
REALM,
SNAME,
ENC_PART;

@Override
public int getValue() {
return ordinal();
}

@Override
public String getName() {
return name();
}
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[] {
new ExplicitField(TKT_VNO, 0, Asn1Integer.class),
new ExplicitField(REALM, 1, KerberosString.class),
new ExplicitField(SNAME, 2, PrincipalName.class),
new ExplicitField(ENC_PART, 3, EncryptedData.class)
};

I like the idea of defining the fields this way, except that I would suggest 
some slight modifications :

- get read of the import ...Ticket.MyEnum.*; [Kai] Hmmm, I guess you mean "get 
rid of", good point. It's like this because, initially we didn't use enum, but 
int constants. And some weeks ago when we want to dump user defined type 
objects like this with meaningful field info, we switched to use enum because 
it can give a friendly name. We were in a hurry at that time and wanted to do 
it as less effort as possible, thus it's like this now: the enum constant is 
rather like int constant and used as before.

- make the enum private (there is no reason we wuld like to expose it anyway) 
[Kai] Well, actually there are some reasons to make it protected and 
disciplined exposed. Such user defined types can be extended and these fields 
may be accessed there. Ref. child classes of ContentInfo (also some other 
examples I remembered when defining protected int constants).

- name it something more meaningful, like TicketField inseatd if MyEnum [Kai] 
Right agree. Again it was like this because it's out as a simple pattern in a 
whole project scope replacement.

- use it with the enum name, like in new ExplicitField(TicketField.TKT_VNO, 0, 
Asn1Integer.class) [Kai] Agree.


I find the "import static xxx.*;" atrocious, most of the time. It makes it 
barely readable : you have to go to the top of your file to actually
*know* where the constant comes from... That may seems of for small files, but 
otherwise... I accept it for Asserts, because it's really clear, in a test 
context - pretty much like annotations.

[Kai] I thought you may be right, but ...

Here is what I come with :

public class Ticket extends KrbAppSequenceType {
public static final int TKT_KVNO = KrbConstant.KRB_V5;
public static final int TAG = 1;

private enum TicketField implements EnumType {
TKT_VNO,
REALM,
SNAME,
ENC_PART;

@Override
public int getValue() {
return ordinal();
}

@Override
public String getName() {
return name();
}
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[] {
ne

RE: [VOTE] Apache DS 2.0.0-M21 release

[Zheng, Kai]

I don't have the chance to check it in details, but would non-binding +1 per my 
understanding of the release and also considering both Java 7 and 8 are 
supported. Thanks!

Regards,
Kai

-Original Message-
From: Stefan Seelmann [mailto:m...@stefan-seelmann.de] 
Sent: Sunday, December 20, 2015 5:34 AM
To: dev@directory.apache.org
Subject: Re: [VOTE] Apache DS 2.0.0-M21 release

+1

* Built with Java 7 and Java 8
* Verified checksums and signatures
* Tested usage in Studio
* Identified issue DIRSERVER-2109 but that is no release blocker.

Kind Regards,
Stefan


On 12/19/2015 10:47 AM, Stefan Seelmann wrote:
> I had hard time to build from the source zip, I'm on Linux with Oracle 
> Java 7. It took me 5 "mvn clean install" to get it pass, once there 
> was a timeout, twice I had a test failure, once the build stuck see 
> partial thread dump below.
> 
> Kind Regards,
> Stefan
> 
> 
> 
> 
> 
> 
> 
> On 12/18/2015 04:04 PM, Emmanuel Lécharny wrote:
>> Hi,
>>
>> now that the vote for a new Apache LDAP API 1.0.0-M33 is out, it's also time 
>> for a new release of ApacheDS 2.0.0-M21.
>>
>> Another bug fix release, nothing really important in it, but we need it for 
>> Studio.
>>
>>
>> The list of fixed bugs and improvments is the following :
>>
>>
>> Bugs :
>> --
>>
>>  * [DIRSERVER-2108 
>> ] - Update 
>> Apache Commons Collections to 3.2.2 due to vulnerability in 3.2.1 
>> 
>>  * [DIRSERVER-2100 
>> ] - Zip file 
>> does not unpack cleanly on case-insensitive OSes 
>> 
>>  * [DIRSERVER-2085 
>> ] - The 
>> PasswordPolicyConfiguration holds the password attribute as a String 
>> 
>>  * [DIRSERVER-2082 
>> ] - User is 
>> allowed to perform all operations even when password must be reset 
>> 
>>  * [DIRSERVER-2075 
>> ] - apacheds.sh 
>> creates a file called '0' during stop action 
>> 
>>
>>
>> Improvements :
>> --
>>  * [DIRSERVER-1901 
>> ] - 
>> subschemaSubentry attribute only available under root DSE 
>> 
>>  * [DIRSERVER-2080 
>> ] - Add a way 
>> to politely stop apacheds from apacheds.sh 
>> 
>>  * [DIRSERVER-2084 
>> ] - Admin user 
>> should be exempt from the pwdHistory check 
>> 
>>
>>
>>
>> Tasks :
>> ---
>>  * [DIRSERVER-2096 
>> ] - Fix 
>> violations of coding standards and enable checkstyle check 
>> 
>>
>>
>>
>>
>>  Here are the associated links :
>>
>> ApacheDS 2.0.0-M21
>> --
>> - SVN tag :
>>
>> http://svn.apache.org/viewvc?rev=1720754=rev
>>
>> https://svn.apache.org/repos/asf/directory/apacheds/tags/2.0.0-M21/
>>
>> - Nexus repository:
>> https://repository.apache.org/content/repositories/orgapachedirectory
>> -1046/
>>
>> - Distribution packages:
>> http://people.apache.org/~elecharny
>>
>>
>> [ ] +1 : release ApacheDS 2.0.0-M21
>> [ ] ± 0 : I don't care
>> [ ] -1 : No, don't release ApacheDS 2.0.0-M21
>>
>> --
>> Regards, Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
> 

RE: [VOTE] Apache LDAP API 1.0.0-M33 release

[Zheng, Kai]

Thanks for the details. The encoding rules are actually much simplified and 
kerby-asn1 would be sure to be able to parse. The problem is I didn't find 
clear ASN1 definitions as we found for Kerberos, PKINIT, CMS and X509. What's 
kerby-asn1 is good at is, starting with a ASN1 defined type, the Java 
pojo/model class can be easily written and the class can be inherently of 
encoding/decoding capabilities and can also be clearly dumped out. Below is an 
example we did recently for CMS. It follows BER encoding, using indefinitive 
length. Without clear ASN1 type definitions, kerby-asn1 would not be much more 
helpful than other ASN1 library supports I'm afraid.

/**
 * Ref. RFC 5652
 * 
 * SignedData ::= SEQUENCE {
 * version CMSVersion,
 * digestAlgorithms DigestAlgorithmIdentifiers,
 * encapContentInfo EncapsulatedContentInfo,
 * certificates [0] IMPLICIT CertificateSet OPTIONAL,
 * crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
 * signerInfos SignerInfos
 *   }
 * 
 *
 */
public class SignedData extends Asn1SequenceType {
protected enum MyEnum implements EnumType {
CMS_VERSION,
DIGEST_ALGORITHMS,
ENCAP_CONTENT_INFO,
CERTIFICATES,
CRLS,
SIGNER_INFOS;
}

static Asn1FieldInfo[] fieldInfos = new Asn1FieldInfo[]{
new Asn1FieldInfo(CMS_VERSION, CmsVersion.class),
new Asn1FieldInfo(DIGEST_ALGORITHMS, DigestAlgorithmIdentifiers.class),
new Asn1FieldInfo(ENCAP_CONTENT_INFO, EncapsulatedContentInfo.class),
new ImplicitField(CERTIFICATES, 0, CertificateSet.class),
new ImplicitField(CRLS, 1, RevocationInfoChoices.class),
new Asn1FieldInfo(SIGNER_INFOS, SignerInfos.class)
};

public SignedData() {
super(fieldInfos);
}

public int getVersion() {
return getFieldAsInteger(CMS_VERSION);
}

public void setVersion(int version) {
setFieldAsInt(CMS_VERSION, version);
}

public DigestAlgorithmIdentifiers getDigestAlgorithms() {
return getFieldAs(DIGEST_ALGORITHMS, DigestAlgorithmIdentifiers.class);
}

public void setDigestAlgorithms(DigestAlgorithmIdentifiers 
digestAlgorithms) {
setFieldAs(DIGEST_ALGORITHMS, digestAlgorithms);
}

public EncapsulatedContentInfo getEncapContentInfo() {
return getFieldAs(ENCAP_CONTENT_INFO, EncapsulatedContentInfo.class);
}

public void setEncapContentInfo(EncapsulatedContentInfo contentInfo) {
setFieldAs(ENCAP_CONTENT_INFO, contentInfo);
}

public CertificateSet getCertificates() {
return getFieldAs(CERTIFICATES, CertificateSet.class);
}

public void setCertificates(CertificateSet certificates) {
setFieldAs(CERTIFICATES, certificates);
}

public RevocationInfoChoices getCrls() {
return getFieldAs(CRLS, RevocationInfoChoices.class);
}

public void setCrls(RevocationInfoChoices crls) {
setFieldAs(CRLS, crls);
}

public SignerInfos getSignerInfos() {
return getFieldAs(SIGNER_INFOS, SignerInfos.class);
}

public void setSignerInfos(SignerInfos signerInfos) {
setFieldAs(SIGNER_INFOS, signerInfos);
}

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, December 18, 2015 5:50 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [VOTE] Apache LDAP API 1.0.0-M33 release

Le 18/12/15 10:34, Zheng, Kai a écrit :
> Got it, thank for the clarifying. 
>
> Would you point to the main RFC spec that contains the ASN1 definition the 
> library implements? I would take a look and see what kerby-asn1 still lacks 
> for it. 

There is no such RFC. The only place where something related to ASN.1 is 
explicited is in RFC 4511 :

4.  Elements of Protocol

   The protocol is described using Abstract Syntax Notation One
   ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding
   Rules ([BER]).  Section 5 specifies how the protocol elements are
   encoded and transferred.


and specifically :

5.1.  Protocol Encoding

   The protocol elements of LDAP SHALL be encoded for exchange using the
   Basic Encoding Rules [BER] of [ASN.1] with the following
   restrictions:

   - Only the definite form of length encoding is used.

   - OCTET STRING values are encoded in the primitive form only.

   - If the value of a BOOLEAN type is true, the encoding of the value
 octet is set to hex "FF".

   - If a value of a type is its default value, it is absent.  Only some
 BOOLEAN and INTEGER types have default values in this protocol
 definition.

   These restrictions are meant to ease the overhead of encoding and
   decoding certain elements in BER.

   These restrictions do not apply to ASN.1 types encapsulated inside of
   OCTET STRING values, such as attribute values, unless otherwise
   stated.


So to speak, this is just a subset of the BER encoding. Note

RE: [VOTE] Apache LDAP API 1.0.0-M33 release

[Zheng, Kai]

This sounds great. Just a thought, the LDAP API would be independent from the 
Directory Server project I guess. If that's right, we might consider have a 
version like 1.1.0 for the release instead of another milestone. Or 1.5.0, 
since 33 milestones would be sure to serve a major release.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, December 18, 2015 4:55 PM
To: Apache Directory Developers List 
Subject: [VOTE] Apache LDAP API 1.0.0-M33 release

Hi,

  This is a vote for the 33th milestone of the 1.0.0 LDAP API/Shared, 1.0.0-M33.

A bug fix releases. We have an improved version of the Ldif anonymizer that 
handles Change records, and a few other fixes (OID handling...)

Here is the list of fixed issues and added features :


Bugs :
--

DIRAPI-245 https://issues.apache.org/jira/browse/DIRAPI-245 -
LdifUtils.convertToLdif(LdifEntry, int) does not honor the 'length'
parameter fully
DIRAPI-258 https://issues.apache.org/jira/browse/DIRAPI-258 - Add
support for the Microsoft LDAP server show deleted objects control 

DIRAPI-260 https://issues.apache.org/jira/browse/DIRAPI-260 - OID
can't process nodes which are bigger than a long 

DIRAPI-261 https://issues.apache.org/jira/browse/DIRAPI-261 - OID
don't encode corrctly joint-iso-itu-t arcs 

DIRAPI-262 https://issues.apache.org/jira/browse/DIRAPI-262 -
misleading message "The matched Dn should not be set when the result code is 
one of..."? 


Task :
--

DIRAPI-257  - Fix
usage of default charset|locale|timezone and enable forbiddenapis check 




The revision :

http://svn.apache.org/viewvc?rev=1720705=rev


The SVN tag:
http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M33
The source and binary distribution packages:
http://people.apache.org/~elecharny/
The staging repository:
https://repository.apache.org/content/repositories/orgapachedirectory-1045


Please cast your votes:
[ ] +1 Release Shared/LDAP API 1.0.0-M33 [ ] 0 abstain [ ] -1 Do not release 
Shared/LDAP API 1.0.0-M33


Emmanuel

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

RE: [VOTE] Apache LDAP API 1.0.0-M33 release

[Zheng, Kai]

Got it, thank for the clarifying. 

Would you point to the main RFC spec that contains the ASN1 definition the 
library implements? I would take a look and see what kerby-asn1 still lacks for 
it. 

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, December 18, 2015 5:14 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [VOTE] Apache LDAP API 1.0.0-M33 release

Le 18/12/15 10:03, Zheng, Kai a écrit :
> This sounds great. Just a thought, the LDAP API would be independent from the 
> Directory Server project I guess. If that's right, we might consider have a 
> version like 1.1.0 for the release instead of another milestone. Or 1.5.0, 
> since 33 milestones would be sure to serve a major release.

We will sooner or later cut a 1.0.0-GA, that's for sure. W ego for Milestone 
because we are missing a couple of features that are important (mainlky referal 
handling). We have been lazzy enough though not to spend the week writing this 
feature ;-)

RE: [VOTE] Apache LDAP API 1.0.0-M33 release

[Zheng, Kai]

Ah, sorry for my bad, it's actually there. From the wiki link, it looks much 
fine for kerby-asn1 to handle if we'd like the approach. Will have some time to 
experiment. Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Friday, December 18, 2015 6:53 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [VOTE] Apache LDAP API 1.0.0-M33 release

Le 18/12/15 11:14, Zheng, Kai a écrit :
> Thanks for the details. The encoding rules are actually much simplified and 
> kerby-asn1 would be sure to be able to parse. The problem is I didn't find 
> clear ASN1 definitions as we found for Kerberos, PKINIT, CMS and X509. What's 
> kerby-asn1 is good at is, starting with a ASN1 defined type, the Java 
> pojo/model class can be easily written and the class can be inherently of 
> encoding/decoding capabilities and can also be clearly dumped out. Below is 
> an example we did recently for CMS. It follows BER encoding, using 
> indefinitive length. Without clear ASN1 type definitions, kerby-asn1 would 
> not be much more helpful than other ASN1 library supports I'm afraid.

The RFC 4511 defines the full ASN.1 grammar for LDAP (at teh end).

You can also have a look at
https://cwiki.apache.org/confluence/display/DIRxSRVx10/Ldap+ASN.1+Codec

RE: Our projects & listing @ the ASF

[Zheng, Kai]

The pages look pretty good to me. Thanks Pierre!!

Regards,
Kai

From: Pierre Smits [mailto:pierre.sm...@gmail.com]
Sent: Tuesday, December 15, 2015 8:30 AM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Our projects & listing @ the ASF

Hi all,

It pleases me to be able to announce that both our (sub) projects Apache 
Fortress and Apache Kerby are now listed at the projects site of the ASF.
For more information see:

  1.  https://projects.apache.org/committee.html?directory
Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Dec 8, 2015 at 2:10 PM, Pierre Smits 
<pierre.sm...@gmail.com<mailto:pierre.sm...@gmail.com>> wrote:
Hi Kai,

For sure, I will suggest that as well (knowing that there are gatekeepers at 
play when it comes to having new categories in).

Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Dec 8, 2015 at 2:03 PM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Hi Pierre,

Thanks for your clarifying. I’m not able to open the web site and may 
misunderstand the purpose. Your approach looks fine to me.
One thing to note, could we add one item in the list like below? I thought 
‘Kerberos’ the key term for Kerby. Thanks.

Kerberos -- Apache Kerby.

Regards,
Kai

From: Pierre Smits 
[mailto:pierre.sm...@gmail.com<mailto:pierre.sm...@gmail.com>]
Sent: Tuesday, December 08, 2015 7:55 PM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Re: Our projects & listing @ the ASF

Hi Kai,

The doap file for each (sub) project will enable that, ensuring that it will be 
properly visible at https://projects.apache.org/

Categorisations, and language definitions will create a visibility regarding 
grouping by:

  *   language(s) applied/used
  *   area of applicability
but these can also help (adopters/users/contributors) regarding joint 
development and cross-pollination activities, such as events, tweeting and more.

Or am I misunderstanding your positing?

Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Dec 8, 2015 at 12:23 PM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Thanks Pierre for sorting this out!

Just a quick thought, another way could be like, listing per project, giving 
each project a dedicated and most distinguished position or summary. This might 
be able to avoid some confusion due to overlaps among these sub projects.

Regards,
Kai

From: Pierre Smits 
[mailto:pierre.sm...@gmail.com<mailto:pierre.sm...@gmail.com>]
Sent: Tuesday, December 08, 2015 7:00 PM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Our projects & listing @ the ASF

Currently the categories to be used for listing our projects is limited.  See: 
http://projects-old.apache.org/categories.html

We should work on having some that suits us better, like:

  *   LDAP - for Apache Directory, Apache Directory Studio, LDAP API, Apache 
Forrtress,
  *   Directory Management - for Apache Directory, Apache Directory Studio
  *   Authentication - for Apache Directory, Apache Directory Studio, LDAP API, 
Apache Forrtress, Apache Kerby
  *   Authorisation - for Apache Directory, Apache Directory Studio, LDAP API, 
Apache Forrtress, Apache Kerby
  *   Identity Management - for Apache Directory, Apache Directory Studio, LDAP 
API, Apache Forrtress,, Apache Kerby
What is your viewpoint on this? Did I miss any alternatives?

Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

FW: [jira] [Created] (DIRKRB-500) Docker building support for integration tests

[Zheng, Kai]

Any thought? I plan to get the initial job done recently because I need a MIT 
Kerberos setup for some bug shooting but don't want to mess my server. Thanks!

Regards,
Kai

-Original Message-
From: Kai Zheng (JIRA) [mailto:j...@apache.org] 
Sent: Sunday, December 13, 2015 5:27 PM
To: dev@directory.apache.org
Subject: [jira] [Created] (DIRKRB-500) Docker building support for integration 
tests

Kai Zheng created DIRKRB-500:


 Summary: Docker building support for integration tests
 Key: DIRKRB-500
 URL: https://issues.apache.org/jira/browse/DIRKRB-500
 Project: Directory Kerberos
  Issue Type: Sub-task
Reporter: Kai Zheng
Assignee: Kai Zheng


This is to propose and support to allow building Kerby in a docker container 
with all kinds of facilities well prepared for integration tests. Somethings 
like:
1. Oracle Java (1.7 and/or 1.8);
2.  MIT Kerberos (client and KDC);
3. Well configured PKINIT;
4. Necessary development tool chains (JDK, GCC/GDB and etc.) for debugging 
failed integration test.

Initially, Linux is considered for the docker container environment.

Additionally but related, some time consuming tests would be marked as 
integration tests and targeted to run in the docker setup. For frequently 
development building, such tests are not to run to speed up. The integration 
tests could be run in the Jenkins building daily.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: About the status of not-so-commons-ssl

[Zheng, Kai]

Thanks Emmanuel for the asking. Let me extract some texts from here 
http://www.infoq.com/news/2007/06/not-yet-commons-ssl. 
The following two features are to be leveraged by implementing PKINIT:

Support more file formats, and support these formats more robustly.

commons-ssl supports over 50 formats of PKCS8 and OpenSSL Encrypted 
Private Keys in PEM or DER
X.509 Certificates can be PEM or DER encoded. Can also come in PKCS7 
chains. (To be fair, Java always supported this.)
PKCS12 files can be in PEM (as created by openssl pkcs12).
Parsing of Base64-PEM is more tolerant of extra whitespace or comments, 
especially outside the Base64 sections.

Automatically detect type of KeyMaterial or TrustMaterial. Consumer does 
not need to know whether keystore is PKCS12 or JKS. They just need to know the 
password to decrypt the private key.

Please note: 
1. The not-so-commons-ssl library is AL 2.0 licensed;
2. Kerby avoids the BC dependency in production codes, though users can inject 
the BC crypto provider themselves;
3. Our version of the SSL library has removed the SSL support part and got away 
with external dependencies like BC, thus of much less codes now.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Sunday, December 13, 2015 12:54 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: About the status of not-so-commons-ssl

Le 13/12/15 00:19, Zheng, Kai a écrit :
> Hi,
>
> Is there anyone that knows the incubating status of the not so commons ssl 
> project? I searched quite a while but don't find it.
> https://wiki.apache.org/incubator/CommonsSSLProposal

6 years old proposal. Dead in the water, IMHO.
>
> I'm considering how to deal with the forked source codes maintained in 
> pkinit-support branch. This is a thing when merge the branch to trunk.
>
> The options are, either evolving based on our forked base towards the way 
> desired by Kerby or, contribute to the project and push what Kerby desired 
> things into it.

What exactly are you using commons-ssl for ? Is there anything you can't do 
with Bouncy-Castle, which is maintained and AL.2.0 compatible ?

About the status of not-so-commons-ssl

[Zheng, Kai]

Hi,

Is there anyone that knows the incubating status of the not so commons ssl 
project? I searched quite a while but don't find it.
https://wiki.apache.org/incubator/CommonsSSLProposal

I'm considering how to deal with the forked source codes maintained in 
pkinit-support branch. This is a thing when merge the branch to trunk.

The options are, either evolving based on our forked base towards the way 
desired by Kerby or, contribute to the project and push what Kerby desired 
things into it.

Thanks.

Regards,
Kai

RE: Our projects & listing @ the ASF

[Zheng, Kai]

Hi Pierre,

Thanks for your clarifying. I’m not able to open the web site and may 
misunderstand the purpose. Your approach looks fine to me.
One thing to note, could we add one item in the list like below? I thought 
‘Kerberos’ the key term for Kerby. Thanks.

Kerberos -- Apache Kerby.

Regards,
Kai

From: Pierre Smits [mailto:pierre.sm...@gmail.com]
Sent: Tuesday, December 08, 2015 7:55 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Our projects & listing @ the ASF

Hi Kai,

The doap file for each (sub) project will enable that, ensuring that it will be 
properly visible at https://projects.apache.org/

Categorisations, and language definitions will create a visibility regarding 
grouping by:

  *   language(s) applied/used
  *   area of applicability
but these can also help (adopters/users/contributors) regarding joint 
development and cross-pollination activities, such as events, tweeting and more.

Or am I misunderstanding your positing?

Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Dec 8, 2015 at 12:23 PM, Zheng, Kai 
<kai.zh...@intel.com<mailto:kai.zh...@intel.com>> wrote:
Thanks Pierre for sorting this out!

Just a quick thought, another way could be like, listing per project, giving 
each project a dedicated and most distinguished position or summary. This might 
be able to avoid some confusion due to overlaps among these sub projects.

Regards,
Kai

From: Pierre Smits 
[mailto:pierre.sm...@gmail.com<mailto:pierre.sm...@gmail.com>]
Sent: Tuesday, December 08, 2015 7:00 PM
To: Apache Directory Developers List 
<dev@directory.apache.org<mailto:dev@directory.apache.org>>
Subject: Our projects & listing @ the ASF

Currently the categories to be used for listing our projects is limited.  See: 
http://projects-old.apache.org/categories.html

We should work on having some that suits us better, like:

  *   LDAP - for Apache Directory, Apache Directory Studio, LDAP API, Apache 
Forrtress,
  *   Directory Management - for Apache Directory, Apache Directory Studio
  *   Authentication - for Apache Directory, Apache Directory Studio, LDAP API, 
Apache Forrtress, Apache Kerby
  *   Authorisation - for Apache Directory, Apache Directory Studio, LDAP API, 
Apache Forrtress, Apache Kerby
  *   Identity Management - for Apache Directory, Apache Directory Studio, LDAP 
API, Apache Forrtress,, Apache Kerby
What is your viewpoint on this? Did I miss any alternatives?

Best regards,

Pierre Smits

ORRTIZ.COM<http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

FW: [jira] [Created] (DIRKRB-490) Separate ASN1 parser

[Zheng, Kai]

Any comment? Your feedbacks are welcome. Thanks.

Regards,
Kai

-Original Message-
From: Kai Zheng (JIRA) [mailto:j...@apache.org] 
Sent: Tuesday, December 08, 2015 6:11 PM
To: dev@directory.apache.org
Subject: [jira] [Created] (DIRKRB-490) Separate ASN1 parser

Kai Zheng created DIRKRB-490:


 Summary: Separate ASN1 parser
 Key: DIRKRB-490
 URL: https://issues.apache.org/jira/browse/DIRKRB-490
 Project: Directory Kerberos
  Issue Type: New Feature
Reporter: Kai Zheng
Assignee: Kai Zheng


*Kerby-asn1* is mainly a user model/type driven or oriented framework. The ASN1 
parsing procedure is tightly coupled with the model value binding process. 
Recent changes made good progress, and this would decouple the two aspects 
totally and provide separate ASN1 parser to cover use cases supported by other 
libraries as well. In other words, users can use this facility to parse data 
stream to emit ASN1 built-in type objects without having to define their models 
or types. This is very handy for small tasks or tools. 

With this separating, the codes for user model type support and value binding 
will also be cleaner and easy to understand, since the part won't care parsing 
logics. With the new parser added, the library will be more complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: FW: [jira] [Created] (DIRKRB-490) Separate ASN1 parser

[Zheng, Kai]

Ah, right. Thanks. Will update when the job is all done. This time the overall 
goal is to support BER encoding/decoding, indefinitive lenghth encoding, 
primitive but constructed encoding/decoding and etc. The codes are almost done, 
but I'm still refining them along with adding more tests. When the newly added 
CMS/X509 models/types (100+) in kerby-pkix module are passed to tests then the 
library will be much proven strong. The rational is, with all the complex types 
involved in Kerberos, CMS and X509 are well supported, the library should be of 
good quality. 

With above said, to move forward, we can experiment to apply it to the LDAP 
field. I believe the codes will be much simplified but let evaluate it then 
after all above done.

Please stay tuned. Thanks.

Regards,
Kai

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Tuesday, December 08, 2015 6:54 PM
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: FW: [jira] [Created] (DIRKRB-490) Separate ASN1 parser

Le 08/12/15 11:14, Zheng, Kai a écrit :
> Any comment? Your feedbacks are welcome. Thanks.

Interesting progress !

I think we could test the lib on the LDAP API, to see if we can use it safely.

That might take a bit of time, but a simple experiment could be fast enough to 
validate the approach.

Definitively worthly !

RE: Our projects & listing @ the ASF

[Zheng, Kai]

Thanks Pierre for sorting this out!

Just a quick thought, another way could be like, listing per project, giving 
each project a dedicated and most distinguished position or summary. This might 
be able to avoid some confusion due to overlaps among these sub projects.

Regards,
Kai

From: Pierre Smits [mailto:pierre.sm...@gmail.com]
Sent: Tuesday, December 08, 2015 7:00 PM
To: Apache Directory Developers List 
Subject: Our projects & listing @ the ASF

Currently the categories to be used for listing our projects is limited.  See: 
http://projects-old.apache.org/categories.html

We should work on having some that suits us better, like:

  *   LDAP - for Apache Directory, Apache Directory Studio, LDAP API, Apache 
Forrtress,
  *   Directory Management - for Apache Directory, Apache Directory Studio
  *   Authentication - for Apache Directory, Apache Directory Studio, LDAP API, 
Apache Forrtress, Apache Kerby
  *   Authorisation - for Apache Directory, Apache Directory Studio, LDAP API, 
Apache Forrtress, Apache Kerby
  *   Identity Management - for Apache Directory, Apache Directory Studio, LDAP 
API, Apache Forrtress,, Apache Kerby
What is your viewpoint on this? Did I miss any alternatives?

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/