ApacheDS official Mastodon account

[Emmanuel Lécharny]

Hi!

I just created a Mastodon account for the project at @apach...@fosstodon.org

Feel free to follow it!

It's likely to replace the apacheds twitter account in the near future.

Thanks!
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: kerby-unsubscr...@directory.apache.org
For additional commands, e-mail: kerby-h...@directory.apache.org

Re: Kerby 2.0.0

[Emmanuel Lécharny]

Le 15/10/2018 à 15:20, Colm O hEigeartaigh a écrit :
> Hi Jiajia,
> 
> My understanding is that the N are still needed as a user can create a
> (binary) distribution from our (source) distribution.

Absolutely, but they are different N files :-)

Usually, there need to be a 'distribution' sub-project that manage to
cut a binary release, and this 'distribution' sub-project will contain
those specific N files.

You can have a look at
https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=tree;f=distribution;h=9fb6cf913a73f1295ef70ec67fcb3a503bd64875;hb=293d6590662bf4f03b3c7321a658bb31d7f303c9


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Kerby 2.0.0

[Emmanuel Lécharny]

Le 11/10/2018 à 08:12, Li, Jiajia a écrit :
> Hi Colm,
> 
> I have added the NOTICE, LICENSE and README, but I have one question, 
> has-server with the hadoop-common(Apache license) dependency, so all the 
> hadoop-common dependency jars will be under the target/lib folder, should we 
> add N for these jars?

You should include all the N of all the dependencies you are bundling
in the released package, including transitive dependencies (ie
dependencies used by the dependencies...)

This is painful, but required.

You can use mvn dependency:tree for that purpose.

Note that the N will change between a binary package and a source
package. Typically, in a source package, if you have dependencies that
are only added while building a binary package, then there is no need to
add them (I'm thinking of installer libraries, for instance).


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: [VOTE] - Release Apache Kerby 1.1.1

[Emmanuel Lécharny]

+1. Built from git and packages. Checked the N files. Good to go.


Side note : we might want to use a tool to verify the N files which
are spread all over the project...


Le 21/05/2018 à 14:12, Colm O hEigeartaigh a écrit :
> This is a vote to release Apache Kerby 1.1.1.
> 
> Artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachedirectory-1156/
> 
> Git tag:
> 
> https://github.com/apache/directory-kerby/tree/kerby-all-1.1.1
> 
> Issues fixed:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310910=12342211
> 
> +1 from me.
> 
> Colm.
> 
> 

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: LDAP backend

[Emmanuel Lécharny]

Le 18/12/2017 à 10:57, Maslova Polina a écrit :
> I have attached the log of kdcinit with the results of search.
> When I tuned on the debug on Apache DS I recieve this in log:

that just means the client has brutally ended its side of the socket.
The server then sends a NoticeOfDisconnect back to the client, which
might be received, as a socket is a 2 ways communication (ie the client
might shut down the client -> server channel, but not the server -> client).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: LDAP backend

[Emmanuel Lécharny]

Le 18/12/2017 à 09:53, Maslova Polina a écrit :
> Dear Jiajia!
> 
> In the kdcinit log I have this 
> 
> 2017-12-18 10:10:11 DEBUG{LdapNetworkConnection.java:2288}-Search successful 
> : MessageType : SEARCH_RESULT_DONE
> Message ID : 2
> Search Result Done
> Ldap Result
> Result code : (SUCCESS) success
> Matched Dn : ''
> Diagnostic message : ''
> 
> 2017-12-18 10:10:11 DEBUG{LdapNetworkConnection.java:511}-Removing <2, 
> org.apache.directory.ldap.client.api.future.SearchFuture>
> 2017-12-18 10:10:11 DEBUG{SearchCursorImpl.java:210}-Closing SearchCursorImpl 
> org.apache.directory.ldap.client.api.SearchCursorImpl@74650e52
> 2017-12-18 10:10:11 DEBUG{SearchCursorImpl.java:225}-Closing SearchCursorImpl 
> org.apache.directory.ldap.client.api.SearchCursorImpl@74650e52
> 2017-12-18 10:10:11  INFO{LdapIdentityBackend.java:129}-closed connection 
> with LDAP.
> 2017-12-18 10:10:11 DEBUG{AbstractIdentityBackend.java:112}-stop called
> 2017-12-18 10:10:11 DEBUG{LdapNetworkConnection.java:777}-received a NoD, 
> closing everything
> 
> 
> at the end of the log. 
> 
> Is it a problems with Apache Directory?

Clearly, no.

The server just send you a SearchResultDone, which is the normal
response when a search request has been processed. We don't have any
information about how may entries have been sent back, as the log have
been truncated just before the SearchResultDone (it would be interesting
to get the previous logs, especially the ones where the searchRequest is
done, and the result entries returned, if any). However, again, this is
an expected response.

The LDAP API client then close the search cursor, as expected when the
search has been processed fully.

What would be interesting is to know why the LdapIdentityBackend class
closed the LDAP connection (this is a Kerby class, it's in teh doStop()
method, and it seems that the close was properly handled).

Jiajia ?

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [DISCUSS] Merge HAS to Apache Kerby

[Emmanuel Lécharny]

Hi Jiajia,


Le 24/11/2017 à 04:30, Li, Jiajia a écrit :
> Hi all,
>
> I would like to post a proposal about merging a new project HAS (Hadoop 
> Authentication Service) to Apache Kerby. HAS is led by Intel and Alibaba, it 
> is a solution to support the authentication of open source big data ecosystem 
> in cloud computing platforms. I've created a new branch "has-project" in 
> Kerby, HAS is under "has" folder. Please look at 
> https://github.com/apache/directory-kerby/tree/has-project/has for details.

Is there some information on HAS, before it was added in a branch ?
Typically, where does it come from (ie, the history), specs,
documentation, etc ?
>
> Background and motivation:
> At present, the open source big data ecosystems (Hadoop/Spark) only has the 
> built-in Kerberos support on the security authentication. HAS aims to build a 
> standalone authentication service for the big data ecosystem that simplifies 
> the support of Kerberos and allows to use more authentication methods.
>
> Targets users:
> HAS supports various authentication mechanisms other than just Kerberos, and 
> it provides a new authentication mechanism can be easy customized and plugin 
> with existing user authentication and authorization system, and security 
> admins won't have to migrate and sync up their user accounts to Kerberos back 
> and forth.
>
> Architecture & Design:
> HAS provides a new authentication mechanism ("Kerberos-based token 
> authentication"), depending on the "TokenPreauth" provided by Apache Kerby. 
> Please look at 
> https://github.com/apache/directory-kerby/blob/has-project/has/README.md for 
> details.
>
> Features:
> 1.  Provides new authentication mechanism plugin APIs to customize and 
> plugin with existing user authentication and authorization system. Please 
> look at 
> https://github.com/apache/directory-kerby/blob/has-project/has/README.md for 
> details.
> 2.  Provides lots of REST APIs and facility tools to simplify the support 
> of Kerberos. Kerberos is essentially a protocol, or secure channel, doesn't 
> have to be that complex to users. Please look at 
> https://github.com/apache/directory-kerby/blob/has-project/has/doc/rest-api.md
>  for details.
> 3.  Provides MySQL backend for High Availability. Please look at 
> https://github.com/apache/directory-kerby/blob/has-project/has/doc/mysql-backend.md
>  for details.
> 4.  New authentication mechanism now supports most of the components of 
> open source big data ecosystem with little or no changes to components, 
> including HDFS, HBase, Zookeeper, Hive, Spark Please look at 
> https://github.com/apache/directory-kerby/tree/has-project/has/supports for 
> details.
>
> Practice
> This solution has been deployed in Alibaba Cloud E-MapReduce production.
>
> Why to merge?
> HAS provides a complete Hadoop/Spark authentication framework and solution 
> based on Kerberos, HAS can help to upgrade Kerby KDC, make it more solid and 
> stronger. And if HAS can be merged to Apache Kerby, community will help HAS 
> grow faster and users can more easily using this solution in their own 
> production. We have two suggestions about how to merge:
> - Option1:
> Create a standalone module "kerby-has", putting HAS project under this module.
> - Option2:
> Suggest replacing kerby-kdc module with HAS, upgrade the Kerby KDC.
>
> Contributors:
> Jiajia, Li (Intel)
> Lin, Zeng (Intel)
> Zhiqiang, Zhang (Intel)
> Kai, Zheng (Intel)
> Wei, Wu (Alibaba)
> Jun, Song (Alibaba)
> Long, Cao (Alibaba)
> Zhenyuan, Wei (Alibaba)

We would really need ICLA for each of those controbutors who haven't
already sent one, and most certain a CCLA from Intel and Alibaba.

Otherwise, assuming we check teh code base is 'safe ' (ie no problem
with any of its dependency, and clean copyright), I would say I won't
oppose to such a move.

Keep in mind that the real key here is the maintenance of this piece of
code in the long run, too...

Thanks !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [DISCUSS] - gitbox migration

[Emmanuel Lécharny]

Le 12/09/2017 à 14:01, Colm O hEigeartaigh a écrit :
> Hi all,
>
> Other git-based projects at Apache, such as the new git repo for the Apache
> Directory LDAP API or Apache CXF, have moved to use gitbox.apache.org. The
> main advantage is that the source is automatically synced with github, and
> hence we can push commits directly to github, thus making merging PRs a lot
> easier.
>
> IMO we should also migrate...any thoughts?

To me, it's a no brainer.
My 2 cts :-)

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [VOTE] - Release Apache Kerby 1.0.1

[Emmanuel Lécharny]

Finaly whipped it :-)


Built from tag and package, N checked : all is good


+1 !


Le 30/08/2017 à 12:30, Colm O hEigeartaigh a écrit :
> 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.
>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [VOTE] - Release Apache Kerby 1.0.1

[Emmanuel Lécharny]

Sorry, I didn't had time to check this release. I'll do that tonite, if
you don't call this vote done already :-)


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

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

[Emmanuel Lécharny]

That should be OK now. Can you check ?


Le 17/05/2017 à 11:40, Colm O hEigeartaigh a écrit :
> No the staging site is fine - the problem is that I don't see the staging
> site pushed to directory.apache.org. For example, the staging site has
> Kerby "1.0.0" since yesterday, but the main published site still has
> "1.0.0-RC2".
>
> Colm.
>
> On Wed, May 17, 2017 at 10:33 AM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
>>
>> Le 17/05/2017 à 10:32, Colm O hEigeartaigh a écrit :
>>> Is it possible to push the staging site manually? I'm still waiting to
>> see
>>> the updates I made propagate through...
>> What commit don't you see on the staging site ?
>>
>> --
>>
>> Emmanuel Lecharny
>>
>> Symas.com
>> directory.apache.org
>>
>>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

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

[Emmanuel Lécharny]

Le 17/05/2017 à 10:32, Colm O hEigeartaigh a écrit :
> Is it possible to push the staging site manually? I'm still waiting to see
> the updates I made propagate through...

What commit don't you see on the staging site ?

-- 

Emmanuel Lecharny

Symas.com
directory.apache.org

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

[Emmanuel Lécharny]

Le 16/05/2017 à 15:42, Colm O hEigeartaigh a écrit :
> Thanks, I guess it takes +24 hours as I made some changes yesterday morning
> that still haven't appeared. Emmanuel - is there any way of seeing what the
> website looks like after changes to the SVN site, but before it gets
> published?

Sure, just check on http://directory.staging.apache.org/kerby/


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

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

[Emmanuel Lécharny]

Le 16/05/2017 à 14:14, Colm O hEigeartaigh a écrit :
> Thanks Emmanuel...where is the staging site?

https://svn.apache.org/repos/asf/directory/site/trunk/ (and under
content/kerby)

Yes. I know. svn.



-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

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

[Emmanuel Lécharny]

Le 16/05/2017 à 11:44, Colm O hEigeartaigh a écrit :
> Yes, the release is done and available in Maven central + the dist. The
> website isn't updated yetis there anything I need to do to trigger the
> update apart from checkin to the website svn?

If the staging site is ok, I can publish it. Just let me know, it's a 10
secs thing.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

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

[Emmanuel Lécharny]

Cheked the source

checked the signature

checked the N files


sounds good to me


+1 !


Le 10/05/2017 à 12:14, Colm O hEigeartaigh a écrit :
> 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.
>
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Emmanuel Lécharny]

Le 09/05/2017 à 14:23, Colm O hEigeartaigh a écrit :
> Hi Kai,
>
> What matters is what jars we are including in the "lib". Any changes Netty
> made to third party dependencies in these jars must be in the
> NOTICE/licenses.

Colm is right.

Now, it's enough - assuming that they have been double checked - to
include Netty's N files in our dist packages, because Netty has
already done the work : ie gathering the dependencies they are using.



I know, I know, this is a painful process...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Emmanuel Lécharny]

Le 09/05/2017 à 12:24, Colm O hEigeartaigh a écrit :
> Thanks Emmanuel. The user would have to add zookeeper/nimbus in the poms
> before generating the distribution to add them, so I am going to remove
> these from the NOTICE file as they are not required.
>
> OK here are the changes I have made...please review:
>
> 1) The root NOTICE just includes the standard Apache copyright notice:
>
> https://github.com/apache/directory-kerby/blob/trunk/NOTICE
>
> 2) The two "distributions" of "kdc-dist" and "tool-dist" have the following
> NOTICE files:
>
> https://github.com/apache/directory-kerby/blob/trunk/kerby-dist/kdc-dist/NOTICE
> https://github.com/apache/directory-kerby/blob/trunk/kerby-dist/tool-dist/NOTICE
>
> and the following identical license folders:
>
> https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/tool-dist/licenses
> https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/kdc-dist/licenses
>
> We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the tool-dist,
> so I think we are covered.


Sounds good to me.

Have you taken into account the transitive dependencies ? (ie, N for
things that are embedded in Netty).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Emmanuel Lécharny]

Le 09/05/2017 à 11:16, Colm O hEigeartaigh a écrit :
> OK, seeing as we don't bundle them by default, then IMO we don't need to
> include them in the NOTICE file. Emmanuel, can you confirm?
Everything that is not bundled does not have to be into N files.

If there is no way a user can grab the sources and generate a package
from those source that contain this bundle, then there is no need to
have the N file in the source either. OTOH, if the user can grab the
source, build it to produce a package that will contain the bundle, then
we need teh N files somwhere so that they get added when the user
build the packaged. In any case, it should not be present in our source
package N

To be very clear : there are two kinds of N files :
- those we include in our source or binary packages (if we provide some).
- those that get included when we generate some packages from the source
package (they are 'second order' N files)

The first category makes our package legit, teh second category protect
our users when they build their own package using our build system
(typically the 'dist' modules).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Emmanuel Lécharny]

Le 08/05/2017 à 21:40, Colm O hEigeartaigh a écrit :
> I don't think we need the Mockito notice as it's a test dependency, right?

right.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Emmanuel Lécharny]

Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
> On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
>>
>> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>>> Hi Emmanuel,
>>>
>>> Is there a wiki page or something that you are aware of at Apache that
>>> clearly lays out what the obligations of projects are for licenses + notice
>>> files for third party dependencies? It's something I've yet to clearly wrap
>>> my head around.
>> I think the page is the one pointed out by Stefan :
>>
>> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>
>> The thing is that it's not really clear to me too, because there is no
>> example on this page.
> Here is another one, that makes it IMHO clear that the source N should
> not include any information about dependencies:
>
> "LICENSE and NOTICE MUST NOT provide unnecessary information about
> materials which are not bundled in the package, such as separately
> downloaded dependencies."
>
> https://www.apache.org/legal/release-policy.html#licensing-documentation
>
>> The logic is the following : we are distributing packages (either
>> sources or bianeis - for convenience, as The ASF is only required to
>> deliver source packages for the users to build them -), and we *must*
>> not give an opportinuty for our users to make a mistake and embed an
>> incompatible component, or forget to add a required notice or license in
>> their own packages, putting them at risk of being sued because of that.
>>
>> We can think that if a company is going to use our packages should do
>> their due diligence, but that is putting too much of a burden on them.
>> More important, it would be very bad PR for The ASF if we were to forgot
>> some of teh required N
> I agree with you. But I think it's two differenct cases:
>
> 1) The content of a distributed package.
> 1a) If the package only contains source code witten by ASF committers or
> the compiled class files then the minimal N applies. (Note: this would
> probably not apply if we would code against an API of an GPL library,
> that's why it's not allowed in ASF projects).
> 1b) If some source code was borrowed e.g. from some 3rd party licensed
> under MIT then we need to include that license and copyright notice.
> 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
> uber jars or binary distribution or installer) then all required N of
> the bundled artifacts have to be added.

On the same page, as soon as we are talking about source package.

>
> 2) The dependencies. As long as they are not bundled then they must not
> be added to N
correct.

>  But of course it's our duty to make sure that all used
> dependencies are compatible to ALv2. And we should be nice to our users
> and list the dependencies. And in fact we do that :). All the Maven
> generated jars contain a META-INF/DEPENDENCIES file with all
> dependencies and its licenses listed. And the Maven generated source zip
> also containse a DEPENDENCIES file The only issue I see is that the
> Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
> empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
> looks fine). It's probably because of the multi-module build, but maybe
> we can tune the Maven release build to include all dependencies for the
> whole project.
>
>> So what does it mean for Kerby, specifically ? Let's check teh different
>> use cases...
>>
>> 1) We are distributing sources only
>>
>> Ok, so we basically don't distribute any binary (libs or exe). Our users
>> *must* build Kerby if they want to use one of the packages, or
>> copy/paste kerby's code in their one code. Are we safe ? Not that much,
>> as building the packages may pull some external dependencies and add
>> them in the produced jars (typically, slf4j). In this case, the produced
>> packages *must* include the embedded jars' N, if they are not fully AL
>> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
>> bundle may have a NOTICE file that requires us to embed it. It could be
>> attribution, a tribute for the cat's author, or anything...)
> Here I disagree. If the users builds it then it's not our duty to
> provide prober N because we don't redistribute what th user builds.

Let me clarify : when we distribute only source package (aka tar.gz of
source files) then this package dos not have to have any N file if we
don't embed binary components (like lib, images, whatever) in the jar,
or when we haven't copy/pasted any snippet of external code.

Now, the trick is that users will take this package and will build
binary packages out of it, a

Questions about the release

[Emmanuel Lécharny]

Hi guys,


I have checked all the modules, and their dependencies. Here is the result :


kerby-all -> test[junit, assertj-core] : OK, no N, test

 |

 +-- kerby-common -> [commons.io] : OK, no N, Apache
 +-- kerby-pkix -> [slf4j-api], test[slf4j-simple, mockito-core] : Need
to add the slf4j N
 +-- kerby-kerb

 ||

 |+-- kerb-core -> OK

 |+-- kerb-common -> [commons.io] : OK, no N, Apache
 |+-- kerb-util -> test[mockito-core] : OK, no N, test
 |+-- kerb-crypto -> OK
 |+-- kerb-identity -> OK
 |+-- kerb-identity-test -> test, no N
 |+-- kerb-client -> test[mockito-core]: OK, no N, test
 |+-- kerb-server -> test[slf4j-simple]: OK, no N, test
 |+-- kerb-kdc-test -> test, no N
 |+-- integration-test -> test, no N
 |+-- kerb-admin -> OK
 |+-- kerb-admin-server -> OK
 |+-- kerb-simplekdc -> OK
 |+-- kerb-client-api-all -> OK
 |+-- kerb-server-api-all -> OK
 +-- kerby-kdc -> [netty-transport, netty-handler, netty-common,
netty-codec, netty-buffer, slf4j-api] : Need to add the slf4j N, add
the netty's NOTICE file

 +-- kerby-tool

 ||

 |+-- client-tool -> OK
 |+-- kdc-tool -> OK

 +-- kerby-kdc-test  -> test, no N
 +-- kerby-backend

 ||

 |+-- ldap-backend -> test[slf4j-simple], OK, no N, test
 |+-- mavibot-backend -> test[slf4j-simple], OK, no N, test
 |+-- json-backend -> [com.google.code.gson], test[slf4j-simple] :
Check the google gson N files.
 |+-- zookeeper-backend-> OK

 +-- kerby-dist

 ||

 |+-- kdc-dist -> [netty, gson, slf4j-api, slf4j-log4j12] : Check
the google gson N files. need to add the slf4j N, add the netty's
NOTICE file
 |+-- tool-dist-> [slf4j-api, slf4j-log4j12] : Need to add the slf4j N

 +-- benchmark -> benchmarks, no N
 +-- kerby-provider

  |

  +- token-provider -> [nimbus-jose-jwt] -> check the
nimbus-jose-jwt N


AFAICT, there are not that many missing bits, but there is one more step
to complete : check the transitive depndencies.

Running mvn dependency:tree on modules which have external dependencies
should give the required informations. Typically, on token-provider,
here is what it gives :


MacBook-Pro:token-provider elecharny$ mvn dependency:tree
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=256M; support was removed in 8.0
[INFO] Scanning for projects...
[INFO]

[INFO]

[INFO] Building Token provider 1.0.0
[INFO]

[INFO]
[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
token-provider ---
[INFO] org.apache.kerby:token-provider:jar:1.0.0
[INFO] +- org.apache.kerby:kerb-core:jar:1.0.0:compile
[INFO] |  \- org.apache.kerby:kerby-pkix:jar:1.0.0:compile
[INFO] | +- org.apache.kerby:kerby-asn1:jar:1.0.0:compile
[INFO] | +- org.apache.kerby:kerby-util:jar:1.0.0:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.25:compile
[INFO] +- com.nimbusds:nimbus-jose-jwt:jar:3.10:compile
[INFO] |  +- net.jcip:jcip-annotations:jar:1.0:compile
[INFO] |  +- net.minidev:json-smart:jar:1.3.1:compile
[INFO] |  +- org.bouncycastle:bcprov-jdk15on:jar:1.52:compile
[INFO] |  \- commons-io:commons-io:jar:2.4:compile
[INFO] +- junit:junit:jar:4.12:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- org.assertj:assertj-core:jar:2.6.0:test
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 1.527 s
[INFO] Finished at: 2017-05-08T06:14:52+02:00
[INFO] Final Memory: 15M/247M
[INFO]



As we can see, nimbus-jose-jwt has itself some dependencies that
requires some N (potentially, that has to be checked) :
jcip-annotations, json-smart and bcprov-jdk15on. If nimbus-jose-jwt has
done its job properly, its N files should already contain the required
bits, but we must check.


This tas has to be ran on all the modules that have noapache and
non-tests dependencies...


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [CANCELLED] Re: [VOTE] - Release Apache Kerby 1.0.0

[Emmanuel Lécharny]

Le 07/05/2017 à 10:31, Colm O hEigeartaigh a écrit :
> I'm cancelling this vote until we have addressed Emmanuel's concerns.
> Emmanuel, can you review the changes Jiajia made?

Can you simply suspend the vote ? I'd like to be sure I'm not 100% wrong
with the N stuff.

We need to have a convo aboit what is released (packages, etc). I'll
post a mail soon.

Thanks !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Sync up

[Emmanuel Lécharny]

Le 27/09/16 à 03:06, Zheng, Kai a écrit :
> An interesting idea indeed! Actually we Chinese have different naming scheme 
> ... sure it would be good when come to consider an English name, but that 
> would only happen when it's really needed, for example, being in a school 
> with many foreigner boys and girls ...

Yes, I as just kidding , of course ;-)

I see that frequently, though, that chinese people pick an 'english'
first name when communicating with western people, probably to ease
communication.

Names and surname are very culturally loaded, and often means something
(which is kind of ignored in western countries, except for a few very
specific surnames), most of the time linked to religion. For instance,
Emmanuel means something like 'god is with us'. You bet it's deceptive,
knowing who I am ;-). My parent picked this name because I was supposed
to be born on december, 24th, and in christian religian, it's supposed
to be the day Jesus was born. Of course, I was born ays before, and I'm
an atheist, but I can't change my first name to something which would
mean 'god is not with me'... Some other surnames are not at all
religious, like Alexander (coming from ancient greek, and means
'defender of men' - alexin : to defend, andros : man).

For MINA, I suspect it comes from the Korean firstname, meaning 'elegant
and fast'... But we would have to ask Trustin, who created the framework :-)

We are all different, with different culture, and this is why this world
is *SO* interesting : you always have something new to learn from others !

Re: Sync up

[Emmanuel Lécharny]

Le 21/09/16 à 10:45, Zheng, Kai a écrit :
> 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
>
>
Just wondering : is it a baby-girl or a baby-boy ? And if it's a
baby-girl what about calling her Mina, and Kerby for a baby-boy ? ;-)
Ok, moving back under my stone ...

Re: Sync up

[Emmanuel Lécharny]

Le 21/09/16 à 10:45, Zheng, Kai a écrit :
> 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. 

Her best release, ever !!! ;-)

Congrats !

Re: Prepare for 1.0.0-RC3

[Emmanuel Lécharny]

Le 27/07/16 à 10:54, Zheng, Kai a écrit :
> Maybe we could release this version as 1.0.0 directly? Any concern? I don't 
> see any. We could claim the authorization feature and remote kadmin support 
> as [EXPERIMENTAL]. 
>
> Sorry too busy recently and don't have bandwidth on this. Hope it can move 
> forward anyway.

That's really up to you ! If there were no complain with the latest RC,
then, yes, delivering a 1.0 would totally make sense.

FTR, in the past, we had a convoluted versionning pattern at Directory
for projects, with numerous milestones. This was plain stupid. I really
like the way Chrome and Firefox are released those days, with a quick
incremental version : each new features added deserve a separate
version, with some potential minor versions for urgent bug fixes.

But this is something you have to discuss, my friends ;-)

Re: Prepare for 1.0.0-RC3

[Emmanuel Lécharny]

Le 27/07/16 à 08:52, Li, Jiajia a écrit :
> Hi all,
>
> March 13, the 1.0.0-RC2 of Kerby was released. We're thinking about a new 
> Kerby release(RC3).
> From Mar 13 to Jul 27, 60 JIRA issues were resolved, including following 
> important features:
>
> 1. Kerby authorization support. Gerard and Richard provided the large patch
> 2. XDR support
> 3. Some remote kadmin API(add, delete and list)
> 4. Some important fixes for JWT pre-authentication and SimpleKdcServer
>
> I thinks the following issues should be solved before release:
> 1. Update the readme and javadoc
> 2. Do some tests of tools.
> What else did I miss here?
>
> How do you think about this?

Hi Jiajia,

this is all good news !

However, I would suggest strongly that for the next iteration of Kerby
(ie, 2.0 or whatever fits your need), you stop using RC when you add
features in the project. There is nothing wrong in releasing many
incremental versions (1.0, 2.0, 3.0..., à la Firefox/Chrome), even if
it's every few months. OTOH, cutting 3 RCs with added features is
conveying a mixed messages to users.

I'm not asking Kerby people to stop doing so know, the train is already
on its way, I'm just suggesting a different approach in the near future :-)

Many thanks and keep going the good work !

Re: About Kerby copyright

[Emmanuel Lécharny]

Le 25/05/16 à 10:41, Zheng, Kai a écrit :
> Yeah, I must learn from you and see how it's well balanced among work, life 
> and open source contribution. :)

Easy : I'm a light sleeper (5:30/6h a night), and I'm married with a
wonderful wife who sleep 10 hours a night ! That leave me with 4 hours a
day at least to play with my computer. But this is a battle ! My wife is
very jealous and think that my computer is my mistress...

Ah, no kid : this helps A LOT (but I'd rather have kids and do less code...)

Re: About Kerby copyright

[Emmanuel Lécharny]

Le 25/05/16 à 00:18, Zheng, Kai a écrit :
> Thanks for the nice asking :)
>
> Haox is just a combination of my two boys' given names. 

Nice !!

> I wished it would make some sense to them because in the whole year I spent 
> lots of my spare time on the initial project having to leave them aside some 
> time :( ...

Yeah... Working on an OSS project is VERY demanding, especially because
we put our soul in it. OTOH, that what make them great ! But familly first !

>
> It's a little pity but I thought Kerby is a perfect name eventually we have. 
> Kerby effort might be slowed down but the wish is still there ...

You now have to have 2 more children, one which givenname starts with
Ker and the second starting with By ;-)

Thanks a lot for the info, this is very refreshing !

Re: About Kerby copyright

[Emmanuel Lécharny]

Le 24/05/16 à 17:12, Zheng, Kai a écrit :
> Thanks Jiajia for thinking about this. Thanks Emmanuel for the info.
>
> Note, Hoax => Haox. The starting date would be 2015 (at the very beginning).
Just curious : does Haox means something in Chinese ?

Otherwise, where does the name come from ?

thanks !

Re: About Kerby copyright

[Emmanuel Lécharny]

Le 24/05/16 à 10:49, Li, Jiajia a écrit :
> I'm writing the Kerby 
> NOTICE(https://github.com/apache/directory-kerby/blob/trunk/NOTICE.txt).
> I'm not sure of the year of copyright, the NOTICE in ApacheDS is (Copyright 
> 2003-2014), how about Kerby? Can anyone help me?
Starting date is 2014, AFAIR (or 2015?). Basically, this is the date the
Hoax contribution has been accepted, but this was at the end of 2014 or
at the very beginning of 2015).

End date is obviously 2016.

Re: Travel to Vancouver and Bay Area

[Emmanuel Lécharny]

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: Release names

[Emmanuel Lécharny]

Le 05/04/16 02:11, Julian Hyde a écrit :
> The semantic versioning site[1] has some examples of what is appropriate, and 
> gives '1.0.0-alpha.1’ as an example of a ‘pre-release version’. In this 
> scheme, Kerby’s releases would be ‘1.0.0-M.1’ and ‘1.0.0-M.2’.

We don't follow that kind of semantic.
>
> I think ‘M’ would be fine, although I still think that ‘beta’ is clearer, 
> because I wouldn’t be sure what ‘M’ stood for. The only thing to avoid would 
> be ‘RC’ since in the Apache world, a release candidate is NOT a release.
In the Apache world, a release is only some package that has a version
and has been voted, period. Using alpha, RC or M is orthogonal and just
a matter of taste.

Now, that the name is not something you are used to, or like, I can
understand. The project can discuss a change after 1.0.0, this is a no
brainer.

Re: [RESULT] [VOTE] Release Apache Kerby 1.0.0-RC2

[Emmanuel Lécharny]

Le 11/03/16 07:52, Zheng, Kai a écrit :
> Thanks for the clarifying. Looks like not just me not knowing this. 
> So a release needs a binding vote only from PMCs, is this specifically for 
> Directory or all ASF projects? 

This is for all the ASF projects : " the basic rule is that only PMC
members have binding votes" (http://www.apache.org/foundation/voting.html)

> Are there any other similar cases in addition to releases? 

Not so much. Usually, PMC members are voting for new committers, new PMC
member, and the chairman. They are also the only ones who can veto a commit.

Now, take it with a bit of distance : non binding votes are *really*
critical. That one or more non-binding committers - or even users -
decide to cast a -1 is generally a very strong indication that something
is going west. You should not discard them as if they count for nothing.

The reason we count PMC members vote as binding is that they represent
the project, and if less than 3 PMC members vote means the project is in
trouble. That also means we should not be too picky about who should
become a PMC member : a constant dedication to the project is clearly a
good sign that the committer should be promoted to the committer status.
In many ways, it makes sense : they feel for the project, they dedicate
some time and energy on it, somehow they *are* the project...

Re: [RESULT] [VOTE] Release Apache Kerby 1.0.0-RC2

[Emmanuel Lécharny]

Le 11/03/16 02:18, Li, Jiajia a écrit :
> Hi guys,
>
> Thanks to all who voted! The vote has passed with the following tally:
>
> +1 Binding (8 total)
> Emmanuel
> Stefan
> Colm
> Kai
> Lin
> Yaning
> Shawn
> Jiajia Li

For clarity, the only binding +1 are Stefan, Colm, Kai, Shawn and me,
which is enough to validate the release :-)

(only PMC's members are binding votes, which does not make the other
vote less important !)

Congrats and hurray for the release !

Re: About project site

[Emmanuel Lécharny]

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 ?

Re: About project site

[Emmanuel Lécharny]

Le 28/01/16 07:36, Zheng, Kai a écrit :
> Sounds good to me. Thanks Jiajia.
>
> The web site looks still old. Is there anyone help with the review and 
> pushing? Or can Jiajia do the pushing so that it can be speed up some bit? 
> Thanks.

Everything that is pushed to the web site goes to
directory.staging.apache.org/kerby. We have to publish it to get it on
directory.apache.org/kerby.

I just have done it.

Re: About project site

[Emmanuel Lécharny]

Le 27/01/16 08:44, Zheng, Kai a écrit :
> I'm not aware of any issue if any.
>
>>> We definitively have to move the 'official' web site to git
> By git, you mean just git or github?

git.
>
>>> so that it can be a sub-project of kerby
> Cool! So we can maintain the docs or the site in the codebase together, 
> instead of having to copy back and forth. Note the developer resources are 
> limited.
yep

Re: About project site

[Emmanuel Lécharny]

Le 26/01/16 09:06, Li, Jiajia a écrit :
> We now changed the docs in github site: 
> http://www.github.com/apache/directory-kerby,

The problem is that it's not what users are seeing.

It would be cool to update the real site instead of pushing the infos on
a github repo which is not the direct facade for Kerby. All in all, the
format is the same (markdown) and if needed, we can switch to git for
the site (it's currently on svn, ftr).

Re: About project site

[Emmanuel Lécharny]

Le 27/01/16 03:15, Li, Jiajia a écrit :
> Hi Emmanuel,
> Thanks for your reminder, as we said in todo list, we will update the website 
> synchronization after the changes done in github repo.
> And now the asn1 changes shows in 
> http://directory.staging.apache.org/kerby/kerby-asn1.html
> And the website may still exist some problems, it will be glad if you can 
> give some advises.

We definitively have to move the 'official' web site to git, so that it
can be a sub-project of kerby. That would make it way more convenient
for you guys.

What are the issues you have with the current web site? How can I help ?

Re: About project site

[Emmanuel Lécharny]

Le 26/01/16 06:49, Zheng, Kai a écrit :
> Hi Jiajia,
>
> The recent project site looks good. Some comments:
>
> Ref. the following, maybe we could rename 1.0.0-RC1-APIs to 1.0.0.-rc1, 
> because we may have more contents other than just APIs related to put it in.
> $ ls -1 docs
> 1.0.0-RC1-APIs/
> 1.0.0-RC2-APIs/

Isn't it the case already ? On http://directory.apache.org/kerby/ we
have a reference to 1.0.0-RC1.

Re: kadmin-remote branch

[Emmanuel Lécharny]

Le 11/01/16 10:18, Zheng, Kai a écrit :
> I don't quite understand your question. Apparently the codes are in some 
> module(s), but isn't relevant to the question that whether it should stay in 
> trunk or a branch. Kadmin-remote is a big new feature that involves 
> significant new codes and currently it's still in its very early phase, 
> therefore I don't think we should do it in trunk.
I probably wasn't clear.

Even if it's a brand new piece of code, I don't see why it should be
seggregated to a branch, instead of being part of the trunk. Being in
trunk does not mean you have to build it with the other modules (enough
to comment it in the main pom), but having it in a branch froces the
developers to switch to the branches to build it. Having it in a branch
makes it painful because even if it's easy to switch from trunk to
branch and back, it's not the same story when it comes to teh IDE
integration (basically, you have to reimport the full project everytime
you switch).

Re: kadmin-remote branch

[Emmanuel Lécharny]

Le 11/01/16 12:12, Zheng, Kai a écrit :
>>> your initial message was "kadmin-remote branch is created for the remote 
>>> kadmin support work.".
> My message here may be a little simple, but I based on the assumption and 
> fact that we have discussed quite much about the feature. 

'Quite much' is an overstatement. Beside one mail you sent in january,
3th, there was no discussion about it.

Not that is is a big problem, though, I just wanted some clarification.
I'm not per se opposed to the crzation of a branch, I'm just asking for
clarification. As I said, creating a branch for such a thing is a real
problem for those using an IDE. But still, it may be a good thing to do.

Frankly, if it has to become a separate tool, I'd rather ask for a new
repo to be created, as we have done in Fortress : that let you work
easily on various projects without dealing with the pain of switching
the branch when you have to work on some parts that are not in the
branch or in the trunk.

Don't get me wrong : this is not a philosophical discussion, nor is it a
blame whatsoever, it's mainly a way to address a potential issue
beforhand. At the end of the day, I would say : 'whatever works'.

It's just that this morning I saw some Jenkcins failure on this branch,
and I told myself : 'uh-oh, why a branch ?' and I tried to check if it
was a good idea, a bad idea, or simply something that has to be
accepted, with the small inconveniences that comes with.


Also don't underestimate the double language barrier : you are not a
native english speaker, I'm nt either a naitve english speaker, so
*many* sentences and words we both are using my be misintepreted... This
makes it difficult to communicate, but we have to gate use to it, it's
not a problem that can be solved magically ! (When I was a kid, I
thought that soon enough we will have soime 'mind reader' machines that
will automatically translate in perfect native language whet someone
else says in his/her own language... Seems like I'll pass away before I
will see these kind of machines !!!)



Anyway, keep going with the good work, and let's go with a branch, if
you thinks it's the way to go !

Re: AP-REP message

[Emmanuel Lécharny]

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

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

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

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

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


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

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

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

Re: Fail to run ' mvn apache-rat:check'

[Emmanuel Lécharny]

Le 04/01/16 08:57, Li, Jiajia a écrit :
> Thanks Kai, I will check my env.

This is a weird error :/

I was able to run mvn apache-rat:check after having add these lines in
my ~/.m2/settings.xml file :

  
org.apache.rat
  

No idea why it works with that, and why it's necessary.

None of the other projects I'm working on (ApacheDS, API, MINA) requires
it...

Re: AP-REP message

[Emmanuel Lécharny]

Le 03/01/16 21:50, Emmanuel Lécharny a écrit :
> Hi,
>
> another class, another question ;-)
>
> (Note that this class is currently not used in Kerby (it will be at some
> point, as this message is sent back to the client as a response to a
> KRB-AP-REQ message when the mutual authent AP-Options is set).)
>
> We have a private EncAPRepPart encRepPart; filed defined. What is it
> good for ? I suspect it's colliding with the ENC_PART field... if so,
> can we get rid of it ?
s/filed/field/

Otherwise, same question for the AP-REQ message, field authenticator,
which sounds spurious to me.

Re: AdToken usage ?

[Emmanuel Lécharny]

Le 04/01/16 06:18, Zheng, Kai a écrit :
> Not yet. There were two PDFs in the docs folder that document about it. 
> They're still drafts but we're still pushing on that.

Ah, good to know !!!

I'll add a reference to this draft in the code.

Thanks Kai !

Re: AP-REP message

[Emmanuel Lécharny]

Le 04/01/16 06:12, Zheng, Kai a écrit :
> It's good to look at the life cycle of these decrypted objects but I don't 
> think it will help a lot if we would do otherwise. Generally decrypting the 
> part and using the decrypted result are not the same place. 

Here is where the encrpted data is decrypetd and used, in KdcRequest :

/**
 * Get the armor key.
 *
 * @throws org.apache.kerby.kerberos.kerb.KrbException e
 * @param fastArmor krb fast armor
 */
private void armorApRequest(KrbFastArmor fastArmor) throws
KrbException {
if (fastArmor.getArmorType() == ArmorType.ARMOR_AP_REQUEST) {
ApReq apReq = KrbCodec.decode(fastArmor.getArmorValue(),
ApReq.class);
...

Authenticator authenticator =
EncryptionUtil.unseal(apReq.getEncryptedAuthenticator(),
encKey, KeyUsage.AP_REQ_AUTH, Authenticator.class);

EncryptionKey armorKey =
FastUtil.cf2(authenticator.getSubKey(), "subkeyarmor",
encKey, "ticketarmor");
setArmorKey(armorKey);
}
}

or in TgsRequest :

public void verifyAuthenticator(PaDataEntry paDataEntry) throws
KrbException {
ApReq apReq = KrbCodec.decode(paDataEntry.getPaDataValue(),
ApReq.class);

...

Authenticator authenticator =
EncryptionUtil.unseal(apReq.getEncryptedAuthenticator(),
encKey, KeyUsage.TGS_REQ_AUTH, Authenticator.class);
...

In both case, we get the encrypted data, we decypt it locally, put the
result in a local variable, which is immediately used and discarded. Its
quite what I'm expecting to see, btw. At no point in the whole kerby
code we use the decrypted value, which is by the way not set in the
encapsulating data structure.

At this point, I can see why it has been added in the structure - in the
spirit that it may be used in a different place in the code than where
it has been decrypted -. But actually, this is not the case.

If you feel like it's better to keep those fields in the classes, so be
it. I'm just afraid we keep them for the sake of keeping them, not
respecting the YAGNI principle
(https://en.wikipedia.org/wiki/You_aren't_gonna_need_it)

Your call !

AdToken usage ?

[Emmanuel Lécharny]

Hi,

there is a class named org.apache.kerby.kerberos.kerb.type.ad.AdToken.
What is it used for ? (there is no reference to this class anywhere in
Kerby code)

AD-TOKEN ::= SEQUENCE {
  token [0]  OCTET STRING,
}

Re: Remaining issues from RC1

[Emmanuel Lécharny]

Le 30/12/15 09:49, Li, Jiajia a écrit :
> Hi all,
> As Kiran said: " we need to improve the packaging of kdc-dist, it is 
> currently copying libraries into the module source root, though it is ignored 
> by Git, it should best be copied to the 'target'
> directory."
>
> Currently the libs are in:
> kerby-dist/kdc-dist/lib/
> kerby-dist/tool-dist/lib/
>
> So I will change to copy the libraries to:
> kerby-dist/kdc-dist/target/
> kerby-dist/tool-dist/target/
>
> Is that right?

IMHO, it does not make that a difference. In MINA, we copy the
dependencies into a /lib sub-directory, which is ignored. But I agree
that copying them into target is also fine, and makes it clear it is
temporary.

So go for it.

Re: PrinciplaName makeSalt method

[Emmanuel Lécharny]

Le 30/12/15 10:46, Zheng, Kai a écrit :
> The logic is either from the spec (3961?) or MIT Kerberos codes. It's 
> intended to form the salt in that way, thus given a certain password for a 
> principal, the generated encryption key will be the same value for an 
> encryption type. All the vendors implement the logic so they can talk to each 
> other for the clients using password. 
http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html#keysalt :
" In Kerberos 5 the complete principal name (including the realm) is
used as the salt . This means that the same password will not result in
the same encryption key in different realms or with two different
principals in the same realm. "

and http://k5wiki.kerberos.org/wiki/Projects/Random_Salt_Generation :

The default salt is specified by RFC 4120
 as "the concatenation of the
principal's realm and name components, in order, with no separators"

and RFC 4120 :

"The default salt string, if none is provided via pre-authentication
data, is the concatenation of the principal's realm and name components,
in order, with no separators."

That explains what.




Here is an interesting read :

http://k5wiki.kerberos.org/wiki/Projects/Random_Salt_Generation

KerberosString

[Emmanuel Lécharny]

Hi,

looking at teh KerberosString class, I think it's not doing the job it's
suppose to do.

Kerberos String is a restricted version of the ASN.1 GeneralString,
limiting the chars that can be used to the ASCII sub-set (ie, 0x00..0x7F).

There is no control whatsoever on the value you can inject into a
KerberosString, and this is extremely dangerous from a interropability POV.

IMO, we shuld override the methods that inject data into a
KerberosString to enforce this mimitation.

There are more things I'd like to say about the Asn1String class, but
I'll submit another mail later !

Thanks !

Re: Rename master branch to trunk and create 1.0.0-RC2 branch for the upcoming release

[Emmanuel Lécharny]

Le 28/12/15 02:12, Zheng, Kai a écrit :
> Hi,
>
> I'd suggest we use 'trunk' instead of 'master' to name the trunk branch as 
> mostly often seen in other projects. 

+1 to that.

> It will be easier understood by new comers.
> Meanwhile, I'll update pom.xml files to use the version like '2.0.0-SNAPSHOT' 
> for the trunk branch, 
Keep it to 1.0.0-RC2-SNAPSHOT. this is what is going to be released.

> and create a branch like 'branch-1.0.0-RC2' using the current version 
> '1.0.0-RC2-SNAPSHOT' for the upcoming release. 

Don't. It's done automatically when we cut the release.

> I thought every release should cut its own branch, though unfortunately we 
> don't have one for the past RC1 release.
of cpurse we have one :
https://git1-us-west.apache.org/repos/asf?p=directory-kerby.git;a=tag;h=4bea5b4979eab53e090bf051a25d1fb017512c55
>
> If no objection, I'll proceed today late. And after that, I'll do some 
> cleanup and move some codes out of the 'branch-1.0.0-RC2' branch to prepare 
> for the release.
The release process will take charge of taht automatically. There is
nothing you need to do, exept may be change from master to trunk.

Re: [kerby] ASN1 Quick review

[Emmanuel Lécharny]

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 <d...@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 standalone as a 
> complete solution some day.
Sure, but I think it's preferable to have a clear vision and design at
each step, which can evolve in the future.

>
> - 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.

Here, that makes more sense.
>
> - 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. 
Forget what I suggested. It's clear that we *need* this interface, it
forces the classes to implement the methods, otehrwise we might forget
doing so, ending with an incomplete 'dump' feature.

Asn1Specifix (which name should probably be Asn1Specifics) should
implement this interface, btw.

Thanks !



http://graphml.graphdrawing.org/xmlns; xmlns:java="http://www.yworks.com/xml/yfiles-common/1.0/java; xmlns:sys="http://www.yworks.com/xml/yfiles-common/markup/primitives/2.0; xmlns:x="http://www.yworks.com/xml/yfiles-common/markup/2.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xmlns:y="http://www.yworks.com/xml/graphml; xmlns:yed="http://www.yworks.com/xml/yed/3; xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns http://www.yworks.com/xml/schema/graphml/1.1/ygraphml.xsd;>
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  

  
  
  
  Asn1Type
  


  

  

  


  
  

  
  
  
  Asn1Encodable
  


  
   

Re: [kerby] ASN1 Quick review

[Emmanuel Lécharny]

Le 24/12/15 01:31, Zheng, Kai a écrit :
> 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 <d...@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.

Okie, so I guess you don't have any provision against the suggested
modification.
>
> - 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).

Okie for 'protected'.

>
> - 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.

Okie. A rename is then possible.

>
> - 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),
>  

Re: [kerby] ASN1 Quick review

[Emmanuel Lécharny]

Le 24/12/15 14:14, Zheng, Kai a écrit :
> Ah it happens so fast and thank you so much. I wish we could have a compiler 
> that accepts the ASN1 module definition files and then help generate/update 
> these classes. It's one thing I want to develop but had better focus on our 
> Kerberos things first. Thanks again.

I have started that years ago. Never had time to go very far :
http://svn.apache.org/repos/asf/labs/dungeon/
>
> I noted our new contributor Yan said she would help with the boring task. 
> Maybe the left can be for her and you take a good rest? She needs to be 
> familiar with such codes anyway.

Your call !

i'll be out anyway for the day, so feel free to task her ;-)

Re: [kerby] ASN1 Quick review

[Emmanuel Lécharny]

Le 24/12/15 10:10, Emmanuel Lécharny a écrit :
> Le 24/12/15 01:31, Zheng, Kai a écrit :
> [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. 
> I can do that. This is typically the kind of (boring) task that I like
> to do when I have little brain cycles (like when it's late, or when I
> don't have energy to focus on serious code : doing boring things make me
> feel I'm still working and contributing to the community).

Just committed a change for almost half of the classes. Piece of cake,
took me less then an hour...

The other half is all in the pkix project.

Re: About refining KrbClient API

[Emmanuel Lécharny]

Le 20/12/15 15:08, Zheng, Kai a écrit :
> Hi all,
>
> I took some time to finish refining the KrbClient API according to some 
> discussion before after some further thinking, please checkout recent commits 
> for the results. There are some ideas left to do but I don't do because 
> they're still arguable. Particularly, exposing AsRequest level as part of the 
> API may be too risk for the moment as the internal implementation is still 
> evolving fast as we're working on more mechanisms like PKINIT. I'm targeting 
> these for RC2, and hope we can stabilize the code base and get RC2 ready the 
> sooner the better, quite much time elapsed after RC1, and we still don't get 
> a formal release yet.

I fully agree that exposing such things like AsRequest is by all means
not necessary...

Can't wait for a RC2 to be ready :-)

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

[Emmanuel Lécharny]

Le 13/12/15 10:31, Zheng, Kai a écrit :
> 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!

That sounds like an option. When I need some env to do some test, I
usually clone a VM on my machine, that does the job too. But if you want
to play around Docker, fine with me.

Re: FW: [jira] [Created] (DIRKRB-490) Separate ASN1 parser

[Emmanuel Lécharny]

Le 08/12/15 12:18, Zheng, Kai a écrit :
> 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. 

There are some very slight difference between LDAP and Kerberos ASN.1
encoding. Typically, the support of BOLEAN can be different (BER vs DER
encoding) : "Kerberos explicitly specifies the use of the Distinguished
Encoding Rules (DER)", when LDAP uses BER.

Re: Kerby client library refactoring

[Emmanuel Lécharny]

Le 29/11/15 02:50, Marc Boorshtein a écrit :
> Sorry, was working on some other projects.  My thought was instead of code
> that looks like this:
>
> requestOptions = new KOptions();
> requestOptions.add(KrbOption.USE_TGT, tgt);
> //requestOptions.add(KrbOption.SERVER_PRINCIPAL,
> "HTTP/freeipa.rhelent.lan");
> requestOptions.add(KrbOption.SERVER_PRINCIPAL, new
> PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
> requestOptions.add(KrbOption.FORWARDABLE,true);
> requestOptions.add(KrbOption.PROXIABLE,false);
> requestOptions.add(KrbOption.RENEWABLE_OK,false);
>
> I would think this would be more OO:
>
> requestOptions = new KOptions();
> requestOptions.setTgt(tgt);
> //requestOptions.setServerPrincipal("HTTP/freeipa.rhelent.lan");
> requestOptions.setServerPrincipal(new
> PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
> requestOptions.setForwardable(true);
> requestOptions.setProxiable(false);
> requestOptions.setRenewable(false);
>
> Could keep it backed by a set of options

Agreed. This is fully compatible with the definition of all the
KrbOptions enums, except thay will not be visible by the end user.

Re: Kerby client library refactoring

[Emmanuel Lécharny]

Le 26/11/15 12:44, Zheng, Kai a écrit :
> Thanks Emmanuel for the feedback and sorry for the late response as focusing 
> on the ASN1 things.
>
>>> If those elements are going to be Enum, keep in mind that you can inherit 
>>> from another enum.
> In current Kerby codes, for options and flags, we favor using the Java enum 
> keyword as a better practice than interfaces of constants.
> The drawback is that it's not extensible, or in other words, an enum can't 
> extend another enum. 

Ahhh, yeah, my bad... Not a big issue though.

Re: SPNEGO negotiation support

[Emmanuel Lécharny]

Le 24/11/15 03:51, Marc Boorshtein a écrit :
> Yep, will do. MS actually has a really good article detailing the asn.1
> structure.
A long time ago (Isuspect ist was back in 2007), I wrote an ASN.1 SPNEGO
codec here is a bit of documentation :
https://cwiki.apache.org/confluence/display/DIRxASN1/SpnegoCodec
Some code :
http://svn.apache.org/viewvc/directory/sandbox/trunk/asn1-new-codec/src/java/org/apache/asn1/spnego/?pathrev=279970
and some tests :
http://svn.apache.org/viewvc/directory/sandbox/trunk/asn1-new-codec/src/test/org/apache/asn1/spnego/codec/?pathrev=279970

10 years old... Not as good as whisky though ;-)

Re: Kerby client library refactoring

[Emmanuel Lécharny]

Le 24/11/15 06:59, Zheng, Kai a écrit :
> There are good feedbacks from Steve recently. Based on discussions with him 
> and Emmanuel, I assembled below thoughts.
>
> KrbClient and its relatives like KrbOption would be broken down according to 
> supported mechanisms and functionalities.
> Eventually we would have these client side APIs for applications to use.
>
> == KrbClient ==
> Focus on classical Kerberos protocol, allowing to request/update tickets to 
> KDC using password, keytab, credential cache and etc.
>
> == KrbPkinitClient ==
> Support PKINIT mechanism, allowing to request tickets to KDC using anonymous 
> and x509 certficate.
>
> == KrbTokenClient ==
> Support standard JWT token, allowing to request tickets to KDC using JWT 
> token.
>
> == KrbPwChange ==
> Change passwd client, interacting with KDC using the change password protocol.
>
> == KrbAdmin ==
> KDC admin utilities compatible with MIT kadmin tool in either local or remote 
> mode. In remote mode interacting  with KDC, though no spec standardizing that.
>
> Note there're already keytab and credential cache utilities.
>
> All these components will define their own options with good specific 
> descriptions;
> For the components that use configurations, krb5.conf is default format;
> For the components that interacts with KDC side servers, common network and 
> message support will be used;
> All will provide both intuitive functions and advanced function that supports 
> directly calling into the underlying layer.
> These library APIs can be used to write tools like kinit, or embedded in 
> applications.
>
> It would be good to provide corresponding server side components or supports, 
> but not mandatory. Better to have at least for easier tests.
>
> When sounds good, we can break this down into smaller tasks and get the major 
> work done before the 1.0.0 formal release.

If those elements are going to be Enum, keep in mind that you can
inherit from another enum. So if you have common elements, feel free to
put them in a parent Enum.

Otherwise, sounds a good idea.

Re: Categorize KrbOption by adding group info

[Emmanuel Lécharny]

Le 20/11/15 10:03, Zheng, Kai a écrit :
>>> I'm not sure I see the point of having one gigantic Enum gathering all the 
>>> possible flags that we can set on any different kerberos element.
> Ok, got your point. Yeah, KrbOption is becoming big, including all kinds of 
> options from frontended mechanism (PKINIT, TOKEN ...), tools (KINIT, Kadmin), 
> and so on. That may be basically because KrbOption(s) accompany with 
> KrbClient and KrbClient is full of all the client side APIs. The centralized 
> APIs may be easier to users to look for and use. 
>
>>> that would make it more complex for coders to know where everything is 
>>> coming from and will disconnect the implementation from the RFC, making it 
>>> harder to understand for new comers that have the RFC in front of them.
> Agree. We should definitely improve this. For now we can add meaningful 
> comments for each group/set of options. Further refactoring and improvement 
> are expected given more thinking and ideas. Will keep this in mind.

Note that it's juts my opinion. I just find it easier to stick to the
RFC, instead of doing it 'à la Microsoft' (ie, redefining everything...)

Re: Categorize KrbOption by adding group info

[Emmanuel Lécharny]

Le 20/11/15 01:44, Zheng, Kai a écrit :
> Hi Steve,
>
> Ref. https://issues.apache.org/jira/browse/DIRKRB-458 you're going to add 
> about 15 KDC flags into KrbOption. As we discussed it sounds reasonable. Now 
> here I'm considering it may be good to categorize them or easily identify 
> them as 'kdc flags', thus it would be much elegant to pick them up and 
> transform them to KdcRequest. How about adding a 'group' field to the 
> KrbOption enum? It could be done while you make the changes or we can do it 
> separately. Thanks.

I'm not sure I see the point of having one gigantic Enum gathering all
the possible flags that we can set on any different kerberos element.
The specification has carefully categorized the various options in
different structures.

IMHO, that would make it more complex for coders to know where
everything is coming from and will disconnect the implementation from
the RFC, making it harder to understand for new comers that have the RFC
in front of them.


KISS...

Re: About favicon.ico in Kerby website

[Emmanuel Lécharny]

Le 23/09/15 15:20, Zheng, Kai a écrit :
> Maybe this isn't a blocker? Guess we could fix this later when available.

It's definitively not a blocker.

Re: Result, was Re: [VOTE] Release Apache Kerby 1.0.0-RC1, take 2

[Emmanuel Lécharny]

Le 22/09/15 04:12, Li, Jiajia a écrit :
> Hi Emmanuel,
>
> Can I do some work for the header and download?

Thanks to Pierre-Arnaud, it's alreayd there ! (at least, on the staging
site)
> I guess we need to upload the zip file to some minors?

The mirrors will get updated automatically, it just takes around 24 h.
> And the header is the news of the release?
It's already done, too.
> Is that right?

I just have to check that everything is fine (links, doiwnloads, etc)
and then commit the site. That should be done today.

The next two steps are :
- announce the release (in 24 h)
- update the site to explain teh release process

Re: Result, was Re: [VOTE] Release Apache Kerby 1.0.0-RC1, take 2

[Emmanuel Lécharny]

Le 22/09/15 08:44, Li, Jiajia a écrit :
> Sounds great!

Okie, I think I fixed the download issue I had.

I encourage all of you to check teh website
(directory.apache.org[/kerby]) to see if all teh links are correct, and
that you can safely download the packages, and check the signatures.

Be aware that, depending on yoru mirror, you might get an error, if it's
not up to date : change teh mirror and see if it's any better.

I created 2 JIRA for some missing elements that need to be addressed for
RC2.

Overall, we have our first release !!!

Last, not least, don't announce it on any social media before the
anncouncement is done (tomorrow, so that we don't have any user
reporting a missing package due to lagging mirrors).

Thanks guy, and congrat, this was a great job !

Re: Result, was Re: [VOTE] Release Apache Kerby 1.0.0-RC1, take 2

[Emmanuel Lécharny]

Le 22/09/15 12:23, Zheng, Kai a écrit :
> Great work, Emmanuel, thanks a lot!
>
>
>
> I checked the web site and also the downloading. Nothing serious is found. 
> Just a minor thing, ref. below snapshot.

The snapshot was removed from the mail...

Re: About favicon.ico in Kerby website

[Emmanuel Lécharny]

Le 22/09/15 16:34, Lin Chen a écrit :
> Hi all,
> A minor issue found in website: Should the color of favicon.ico be 
> changed? For now the icon is the same as that in LDAP API. Snapshot below.
FTR, the mailing list manager removes all the attachements.

Yes, we would need a new favicon for kerby.

Re: Result, was Re: [VOTE] Release Apache Kerby 1.0.0-RC1, take 2

[Emmanuel Lécharny]

Le 21/09/15 10:25, Li, Jiajia a écrit :
> Hi Emmanuel,
> Are there any update and more things to do for the release?
Hi Jiajia,

sorry for having delayed the web-site update. It's a work in progress,
and there are a few missing parts.

Here the current sstaging site :
http://directory.staging.apache.org/kerby/

As you can see, there is no header (yet), and the download links are not
(yet) working.

More to come later tonite when I'll have a few more hours to work on it.

FTR, there are two things I can't change atm : the hdead and the
download badge, because I don't have the tools for that.

Result, was Re: [VOTE] Release Apache Kerby 1.0.0-RC1, take 2

[Emmanuel Lécharny]

Hi guys,

I'm therefore closing the vote, which was a success with 6 +1 and 2 +0

+1 :
Stefan,
Kiran,
Yaning,
Kai,
Colm
and me

+0 :
Jiajia,
Felix


I'll publish the packages soon.

Many thanks and congrats for this very first release !

[VOTE] Release Apache Kerby 1.0.0-RC1, take 2

[Emmanuel Lécharny]

Hi !

this is the very first release of Apache Kerby, 1.0.0-RC1 (second attempt). 
This is a
release candidate, which means we are reaching an API freeze, but some
bug might be fixed before we move to an official GA.


Please cast your vote !

The revision :

http://git-wip-us.apache.org/repos/asf/directory-kerby/commit/69d63691

The source packages are available here :
http://people.apache.org/~elecharny/

The staging repository:
https://repository.apache.org/content/repositories/orgapachedirectory-1042/

Please cast your votes:
[ ] +1 Release Apache Kerby 1.0.0-RC1
[ ] 0 abstain
[ ] -1 Do not release Apache Kerby 1.0.0-RC1

Re: state of KDC

[Emmanuel Lécharny]

Le 03/08/15 16:58, Zheng, Kai a écrit :
 I just thought of another two items to do for the release. They came to my 
 mind during related discussions.
 1. Double check all the left issues/JIRAs. If not must to have, we can 
 retarget them for 1.0.0-rc2, 1.0.0, and 2.0.0 accordingly.
 2. Mavibot backend, it still relying on SNAPSHOT version of Mavibot. If 
 sounds good, how about retargeting it for 1.0.0, and move it out of the 
 release?

 Kiran, would you comment on this? Thanks.
We can cut a release of Mavibot, but it will be a Milstone, not a RC. In
any case, if needed, we can either discard the Mavobot backend, or if we
have a RC for Mavinot, use it.

Re: Parent POM

[Emmanuel Lécharny]

Le 03/08/15 19:50, Stefan Seelmann a écrit :
 Hi,

 as we plan to do a release, I noticed that the Kerby parent POM does not
 inherit from another POM, neither the Directory project [1], nor the
 general ASF POM [2].

 When the plan is to move Kerby sooner or later to its own TLP it may not
 make sense to inherit from [1]. But at leasst [2] should be set as
 parent. It contains lot fo configuration required for releasing,
 including legal checks (apache-rat-plugin), source plugin for creating
 source JARS, GPG plugin for signing JARs, distribution managent, etc.

 Thoughts?

I think it's harmless to depend on the general pom. We can also make the
project depend from the 'project' parent pom, to ease the process, at
least for the very first release, as it already declares a hell lot of
dependencies, but I would agree that it's not necessary in the long run.

Your choice, guys !

Re: Kerby interest

[Emmanuel Lécharny]

Le 29/07/15 22:52, Tom Mueller a écrit :
 Greetings,

 Kerby is new to me but I'm quite excited about what it has to offer.  The 
 project goals look great as an embeddable Java Kerberos implementation is 
 really needed. Having read through the material on the website, downloaded 
 and built the code, and experimented with it to some extent, our team is 
 ready to take the next step with Kerby.

 I saw the Kerby Status Summary that was posted on July 3, but I didn't find 
 anything there about plans to publish the maven modules to maven central or 
 some other publicly available maven repository.  Is there a projected date 
 for that?

No projected date yet. The very first step would be to cut a first
release, this is something that has already been discussed, but not uyet
decided.

 We have interest in the PKINIT implementation that was reported as about 50% 
 completed as of July 3. How can I get involved with helping to complete that 
 implementation?

This is open source ! You are very welcome to submit patches. The best
approach would be to check what's in JIRA related to PKInit, or simply
start playing with the current code, and propose improvements.

Thanks !

Re: How to implement getIdentities(int start, int limit) more effectively

[Emmanuel Lécharny]

Le 06/07/15 07:06, Zheng, Kai a écrit :
 Yaning,

 How about going on with this simple API change, as previously proposed by 
 Stefan? I thought it can server well the same purpose for cursor.

 ListString getIdentities(int start, int limit)
 =
 IteratorString getIdentities()

I'll suggest - again - a different approach :
- either you return a cursor
- or you keep the ListString

Here is why : Cursor already implements Iterable, so if you drink the
cool aid fully, you'll get the equivalent to what you propose.

But if you consider it's still too much work, then, please, keep it
simple and use ListString getIdentiies() at the moment.

Re: Jenkins job for Kerby

[Emmanuel Lécharny]

Le 03/07/15 10:53, Zheng, Kai a écrit :
 Would anyone let me know how to subscribe notificati...@directory.apache.org? 
 Thanks.

Send a mail to notifications-subscr...@directory.apache.org

No need to add a subject or an object.

Re: Code quality formatting rules

[Emmanuel Lécharny]

Le 02/07/15 11:36, Zheng, Kai a écrit :
 Thanks Emmanuel again for sorting this out. Some lazy guys like me should 
 definitely be more careful and keep the mentioned points in mind before 
 commit. Some notes here.

 The README.md file has none.
 I don't know if github markdown supports comment or not. Need to see if 
 doable for the READMEs.

It does :

Title: Table widget
Notice: Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at
.
http://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

But please feel free to doublecheck.

 About Javadoc, I'm wondering if we would allow some exceptions for test 
 codes, because from my point of view, we could make the class names and 
 methods good long enough readable and understandable.

Absolutely right. Test code does not need the level of Javadoc we use
for real code, especially for methods. I usually just add a Class
header, and a method header which just tells what is the method testing.
Nothing fancy.


 To be more spot on : it's absolutely critical to add Javadoc in Interfaces 
 : this is what get exposed to the public.
 Sure! Absolutely. I'm going to add missing ones for the existing APIs.

 About coding styles, I agree totally. Need to fix the found issues 
 immediately. Sometime it would be great to have checking styles to be 
 enforced so such exceptions can be found soon once they get in.

We have a Jenkins server that build Kerby every day, and it provides a
good set of rules violation :
https://analysis.apache.org/dashboard/index/212397