[jira] [Assigned] (DIRKRB-135) Add logging support in both KDC and KrbClient
[ https://issues.apache.org/jira/browse/DIRKRB-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-135: Assignee: (was: Emmanuel Lecharny) Add logging support in both KDC and KrbClient - Key: DIRKRB-135 URL: https://issues.apache.org/jira/browse/DIRKRB-135 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Currently no logging is done in either KDC server or KrbClient, which is far from ideal. We should output meaningful logs help troubleshooting. I guess we could leverage slf4j library or just use the Java logging API? The latter would be better in the sense that we won't introduce a 3rd party library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-172) Working on a standalone KDC server
[ https://issues.apache.org/jira/browse/DIRKRB-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-172: Assignee: (was: Kai Zheng) Working on a standalone KDC server -- Key: DIRKRB-172 URL: https://issues.apache.org/jira/browse/DIRKRB-172 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng We're working on a standalone KDC server, running, testing, and fixing. This is to track all the related issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-131) Decouple Kerberos from the Directory Server
[ https://issues.apache.org/jira/browse/DIRKRB-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-131: Assignee: (was: Kiran Ayyagari) Decouple Kerberos from the Directory Server --- Key: DIRKRB-131 URL: https://issues.apache.org/jira/browse/DIRKRB-131 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng As discussed in the mailing list, we would decouple Kerberos logics from the Directory Server, to better maintain the dependencies and avoid the complexities. In the end, the Directory Server can be used as an identity backend for the KDC server in the plugin or dynamical loading approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-132) Decouple Kerberos from the Directory Studio
[ https://issues.apache.org/jira/browse/DIRKRB-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-132: Assignee: (was: Emmanuel Lecharny) Decouple Kerberos from the Directory Studio --- Key: DIRKRB-132 URL: https://issues.apache.org/jira/browse/DIRKRB-132 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng As discussed in the mailing list, we would decouple Kerberos logics from the Directory related projects and codes, to better maintain the dependencies and avoid the complexities. The Directory Studio should be also taken care of, but I'm not sure we would totally remove the embedded KDC server from the tool itself since that involves compatibility concern. Please give your feedback here, thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-130) Consolidate the existing Change Password protocol implementation
[ https://issues.apache.org/jira/browse/DIRKRB-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-130: Assignee: (was: Emmanuel Lecharny) Consolidate the existing Change Password protocol implementation Key: DIRKRB-130 URL: https://issues.apache.org/jira/browse/DIRKRB-130 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Currently the existing Kerberos implementation in ApacheDS contains the Change Password protocol server. This is to consolidate the functionality into the new KDC server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-109: Assignee: (was: Emmanuel Lecharny) We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Attachments: DIRKRB-109_v3.png, DIRKRB-109_v4.png, logo draft.png, logo with color.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-123) Implementing cross-realm support
[ https://issues.apache.org/jira/browse/DIRKRB-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-123: Assignee: (was: Emmanuel Lecharny) Implementing cross-realm support Key: DIRKRB-123 URL: https://issues.apache.org/jira/browse/DIRKRB-123 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng This is going to implement the cross-realm support, which can be used to build trust relationship with MIT Kerberos KDC or MS AD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-173) A Zookeeper based high reliable performance identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14377255#comment-14377255 ] Kai Zheng commented on DIRKRB-173: -- Currently there's only basic setup for the back end. As I will focus on the FAST framework and some mechanisms, don't have time for it recently. Marked it as unassigned. A Zookeeper based high reliable performance identity backend -- Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng This will create a Zookeeper based identity backend targeting for high reliable and high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-188) Calculating FAST armor key
Kai Zheng created DIRKRB-188: Summary: Calculating FAST armor key Key: DIRKRB-188 URL: https://issues.apache.org/jira/browse/DIRKRB-188 Project: Directory Kerberos Issue Type: New Feature Reporter: Kai Zheng Assignee: Kai Zheng According to the FAST spec, in section of https://tools.ietf.org/html/rfc6113#page-17, we need to implement the facility for calculating armor key given key1, key2, pepper1, and pepper2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-188) Calculating FAST armor key
[
https://issues.apache.org/jira/browse/DIRKRB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng updated DIRKRB-188:
-
Description:
According to the FAST spec, in section of
https://tools.ietf.org/html/rfc6113#page-17, we need to implement the facility
for calculating armor key given key1, key2, pepper1, and pepper2, as defined as
follows.
{noformat}
KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
function defined in [RFC3961].
Given two input keys, K1 and K2, where K1 and K2 can be of two
different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
follows:
KRB-FX-CF2(protocol key, protocol key, octet string,
octet string) - (protocol key)
PRF+(K1, pepper1) - octet-string-1
PRF+(K2, pepper2) - octet-string-2
KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
random-to-key(octet-string-1 ^ octet-string-2)
Where ^ denotes the exclusive-OR operation. PRF+() is defined as
follows:
PRF+(protocol key, octet string) - (octet string)
PRF+(key, shared-info) := pseudo-random( key, 1 || shared-info ) ||
pseudo-random( key, 2 || shared-info ) ||
pseudo-random( key, 3 || shared-info ) || ...
{noformat}
was:According to the FAST spec, in section of
https://tools.ietf.org/html/rfc6113#page-17, we need to implement the facility
for calculating armor key given key1, key2, pepper1, and pepper2.
Calculating FAST armor key
--
Key: DIRKRB-188
URL: https://issues.apache.org/jira/browse/DIRKRB-188
Project: Directory Kerberos
Issue Type: New Feature
Reporter: Kai Zheng
Assignee: Kai Zheng
According to the FAST spec, in section of
https://tools.ietf.org/html/rfc6113#page-17, we need to implement the
facility for calculating armor key given key1, key2, pepper1, and pepper2, as
defined as follows.
{noformat}
KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
function defined in [RFC3961].
Given two input keys, K1 and K2, where K1 and K2 can be of two
different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
follows:
KRB-FX-CF2(protocol key, protocol key, octet string,
octet string) - (protocol key)
PRF+(K1, pepper1) - octet-string-1
PRF+(K2, pepper2) - octet-string-2
KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
random-to-key(octet-string-1 ^ octet-string-2)
Where ^ denotes the exclusive-OR operation. PRF+() is defined as
follows:
PRF+(protocol key, octet string) - (octet string)
PRF+(key, shared-info) := pseudo-random( key, 1 || shared-info ) ||
pseudo-random( key, 2 || shared-info ) ||
pseudo-random( key, 3 || shared-info ) || ...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370895#comment-14370895 ] Kai Zheng commented on DIRKRB-109: -- Emmanuel, I agree. Let's have it for now as we would allow very initial codes in. We can always improve incrementally later when have more hands. I believe we can find first-class logo designer some time afterwards. We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Assignee: Emmanuel Lecharny Attachments: DIRKRB-109_v3.png, DIRKRB-109_v4.png, logo draft.png, logo with color.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-181) Better to use pretty Json format for the Json backend file
Kai Zheng created DIRKRB-181: Summary: Better to use pretty Json format for the Json backend file Key: DIRKRB-181 URL: https://issues.apache.org/jira/browse/DIRKRB-181 Project: Directory Kerberos Issue Type: Improvement Reporter: Kai Zheng Better to use pretty Json format for the Json backend file, for easier looking at and troubleshooting. Please google for it using Gson pretty print. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-180) Better to use string representation of keys in Json backend file
Kai Zheng created DIRKRB-180:
Summary: Better to use string representation of keys in Json
backend file
Key: DIRKRB-180
URL: https://issues.apache.org/jira/browse/DIRKRB-180
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Better to use string representation for principal keys in Json backend file. We
can use {{bytesToHex}} for it, using {{bytesToHex}} and {{hex2bytes}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRKRB-135) Add logging support in both KDC and KrbClient
[ https://issues.apache.org/jira/browse/DIRKRB-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368097#comment-14368097 ] Kai Zheng commented on DIRKRB-135: -- Sorry for late on this. What might concern me about slf4j is it may add overhead or difficulty for porting the lib to android platform in future. But just google let me find below, which shows that it's just a perfect choice ! http://www.slf4j.org/android/ Will use slf4j consistently in the project, for simple. Thanks for you idea. Add logging support in both KDC and KrbClient - Key: DIRKRB-135 URL: https://issues.apache.org/jira/browse/DIRKRB-135 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Emmanuel Lecharny Currently no logging is done in either KDC server or KrbClient, which is far from ideal. We should output meaningful logs help troubleshooting. I guess we could leverage slf4j library or just use the Java logging API? The latter would be better in the sense that we won't introduce a 3rd party library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-178) Improve configuration library allowing to pluggin configuration format support
Kai Zheng created DIRKRB-178: Summary: Improve configuration library allowing to pluggin configuration format support Key: DIRKRB-178 URL: https://issues.apache.org/jira/browse/DIRKRB-178 Project: Directory Kerberos Issue Type: Improvement Reporter: Kai Zheng Assignee: Kai Zheng This to enhance configuration framework to allow customizing and pluggin of configuration format loader, which will be used to support MIT configuration format by kerberos in more elegant way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-102) [Apache Kerby] A dedicated Kerberos project
[ https://issues.apache.org/jira/browse/DIRKRB-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368523#comment-14368523 ] Kai Zheng commented on DIRKRB-102: -- A mirror of the project was created in Github. https://github.com/apache/directory-kerby [Apache Kerby] A dedicated Kerberos project Key: DIRKRB-102 URL: https://issues.apache.org/jira/browse/DIRKRB-102 Project: Directory Kerberos Issue Type: New Feature Reporter: Kai Zheng Labels: Kerberos As discussed in the community, we're going to create a dedicated Kerberos project based on Haox project codebase (https://github.com/drankye/haox) incorporating and consolidating the existing Kerberos functionalities in ApacheDS. The long term goal is to establish a first class Kerberos implementation in Java for the Apache world targeting today's environments in cloud, Hadoop and mobile. It will provides rich, intuitive and interoperable library and facilities that integrate multiple authentication mechanisms including PKI, OTP and token (OAuth) as desired in above mentioned modern environments.It will also implement a KDC server that can integrate various identity back ends including simple memory database, SQL database and LDAP server by dynamic plugin and loading approach, which allows it to be utilized in various contexts and scenarios. This serves as the master JIRA to track all the related tasks for the new sub project. With the fundamental aspects and tasks resolved, we would go to next phase targeting an Apache TLP project, as we agreed in the discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-179) Adding kadmin tool to support the KDC
Kai Zheng created DIRKRB-179: Summary: Adding kadmin tool to support the KDC Key: DIRKRB-179 URL: https://issues.apache.org/jira/browse/DIRKRB-179 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng A kadmin like tool is needed to support the KDC server. Initially only local mode is supported, in other words, the tool should only be run locally on the KDC server host, and in this case it can operate the identity backend directly as 'root' user without worrying about security concerns. At this time two basic operations are definitely needed, creating principal and exporting keytab file. We can implement the tool incrementally after that in the following. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-175) Extend Config API to allow set values in additon to get values
Kai Zheng created DIRKRB-175: Summary: Extend Config API to allow set values in additon to get values Key: DIRKRB-175 URL: https://issues.apache.org/jira/browse/DIRKRB-175 Project: Directory Kerberos Issue Type: Improvement Reporter: Kai Zheng Assignee: Kai Zheng This will extend *Config* API to allow set values, which will help a lot in test cases, since we don't have to prepare configuration files, a map or a properties. We can directly set test configuration values to the Config object to prepare for it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-175) Extend Config API to allow set values in additon to get values
[ https://issues.apache.org/jira/browse/DIRKRB-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-175. -- Resolution: Fixed commit 9ca5d36e4072ff1d1721bedc0683df7637739739 Author: Drankye dran...@gmail.com Date: Wed Mar 18 05:43:06 2015 +0800 DIRKRB-175 Extend Config API to allow set values in additon to get values Extend Config API to allow set values in additon to get values -- Key: DIRKRB-175 URL: https://issues.apache.org/jira/browse/DIRKRB-175 Project: Directory Kerberos Issue Type: Improvement Reporter: Kai Zheng Assignee: Kai Zheng This will extend *Config* API to allow set values, which will help a lot in test cases, since we don't have to prepare configuration files, a map or a properties. We can directly set test configuration values to the Config object to prepare for it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-176) Adding klist utility tool
[ https://issues.apache.org/jira/browse/DIRKRB-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364831#comment-14364831 ] Kai Zheng commented on DIRKRB-176: -- Thanks Liqi for taking this. Yes this tool is needed for a comprehensive solution, and can also be used to exercise/test our library codes. Adding klist utility tool - Key: DIRKRB-176 URL: https://issues.apache.org/jira/browse/DIRKRB-176 Project: Directory Kerberos Issue Type: Sub-task Reporter: Liqi Yi Original Estimate: 672h Remaining Estimate: 672h The klist command allows current Kerberos user to view his/her Ticket Granting Service tickets that are in the ticket cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-102) [Apache Kerby] A dedicated Kerberos project
[ https://issues.apache.org/jira/browse/DIRKRB-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364150#comment-14364150 ] Kai Zheng commented on DIRKRB-102: -- To reflect the new project name *Apache Kerby*, the git repo was changed to: https://git-wip-us.apache.org/repos/asf/directory-kerby.git [Apache Kerby] A dedicated Kerberos project Key: DIRKRB-102 URL: https://issues.apache.org/jira/browse/DIRKRB-102 Project: Directory Kerberos Issue Type: New Feature Reporter: Kai Zheng Labels: Kerberos As discussed in the community, we're going to create a dedicated Kerberos project based on Haox project codebase (https://github.com/drankye/haox) incorporating and consolidating the existing Kerberos functionalities in ApacheDS. The long term goal is to establish a first class Kerberos implementation in Java for the Apache world targeting today's environments in cloud, Hadoop and mobile. It will provides rich, intuitive and interoperable library and facilities that integrate multiple authentication mechanisms including PKI, OTP and token (OAuth) as desired in above mentioned modern environments.It will also implement a KDC server that can integrate various identity back ends including simple memory database, SQL database and LDAP server by dynamic plugin and loading approach, which allows it to be utilized in various contexts and scenarios. This serves as the master JIRA to track all the related tasks for the new sub project. With the fundamental aspects and tasks resolved, we would go to next phase targeting an Apache TLP project, as we agreed in the discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-173) A Zookeeper based high reliable performance identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364421#comment-14364421 ] Kai Zheng commented on DIRKRB-173: -- Hi Kiran, Glad to have this discussion. We don't have specific usecase, but I thought the background would be Hadoop, and cloud, where high reliability, high performance and high scalability are highly desirable for any potential component to be hooked into. Zookeeper would be a good choice in this aspect. It's demonstrated in wide spread usages in big data and cloud environments as the coordination brain, critical configuration storage and etc. Yes it's also lightweight and can be embedded. It's also a tree, each znode being of key-value pairs. Looks like we share the same considerations in this, I don't like RDBMS here. Lin's working on the Json based one for its easy lightweight and inspecting; I'm working on this for any serious consideration. I guess we should also get the LDAP one out, but with the Json file based one and ZK based one out, we may be sure to have more ideas how to implement it. A Zookeeper based high reliable performance identity backend -- Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This will create a Zookeeper based identity backend targeting for high reliable and high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-173) A Zookeeper based high reliable performance identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364554#comment-14364554 ] Kai Zheng commented on DIRKRB-173: -- We have a memory store using a capacity configurable hashmap and it's used by default. But as it doesn't work with any kadmin stuff so we need a persistent one. Json based would be much easy to be out first. An LDAP one can be out later I guess, let we see if any contribution interest. Anyway, given the common test framework for backends and we have the Json based and ZK based in hand, it would be much easier for the LDAP one since we only need do the very LDAP specific things. I thought we need to have the LDAP backend done before the first release of the sub project, which makes it well connected with the main parts (LDAP). Makes sense ? Thanks. A Zookeeper based high reliable performance identity backend -- Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This will create a Zookeeper based identity backend targeting for high reliable and high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-173) A Zookeeper based high reliable performance identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364563#comment-14364563 ] Kai Zheng commented on DIRKRB-173: -- Sounds good to me. Before the time, I will also communicate about it with potential contributors. I may also have some time for it. A Zookeeper based high reliable performance identity backend -- Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This will create a Zookeeper based identity backend targeting for high reliable and high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-171) No response to client when incorrect password
[ https://issues.apache.org/jira/browse/DIRKRB-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362277#comment-14362277 ] Kai Zheng commented on DIRKRB-171: -- Added some negative tests like incorrect password and ensure KDC not be affected by bad client requests. No response to client when incorrect password - Key: DIRKRB-171 URL: https://issues.apache.org/jira/browse/DIRKRB-171 Project: Directory Kerberos Issue Type: Improvement Reporter: Lin Chen Assignee: Kai Zheng When client request a ticket from kdc server, client should input a password. If the password is incorrect, server will throw many exceptions but the client would not get any response about what's wrong. Maybe it is not very user-friendly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-135) Add logging support in both KDC and KrbClient
[ https://issues.apache.org/jira/browse/DIRKRB-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362183#comment-14362183 ] Kai Zheng commented on DIRKRB-135: -- Thanks Emmanuel. I agree SLF4J will be the right choice. I will use it in server side first. For client and the library, I'm thinking about an even lighter one. Add logging support in both KDC and KrbClient - Key: DIRKRB-135 URL: https://issues.apache.org/jira/browse/DIRKRB-135 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Emmanuel Lecharny Currently no logging is done in either KDC server or KrbClient, which is far from ideal. We should output meaningful logs help troubleshooting. I guess we could leverage slf4j library or just use the Java logging API? The latter would be better in the sense that we won't introduce a 3rd party library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-110) Refine the IdentityService/Backend API for KDC
[ https://issues.apache.org/jira/browse/DIRKRB-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-110: Assignee: Kai Zheng (was: Kiran Ayyagari) Refine the IdentityService/Backend API for KDC -- Key: DIRKRB-110 URL: https://issues.apache.org/jira/browse/DIRKRB-110 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng Currently a simple IdentityService API is defined and various KDC database backends can be implemented. Via this, all database specific dependencies can be separated and decoupled from KDC. Given this API is refined and made sure to serve the role, we can add to implement an LdapIdentityBackend using the ApacheDS LDAP server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-110) Refine the IdentityService/Backend API for KDC
[ https://issues.apache.org/jira/browse/DIRKRB-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-110. -- Resolution: Fixed It was already done. Refine the IdentityService/Backend API for KDC -- Key: DIRKRB-110 URL: https://issues.apache.org/jira/browse/DIRKRB-110 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng Currently a simple IdentityService API is defined and various KDC database backends can be implemented. Via this, all database specific dependencies can be separated and decoupled from KDC. Given this API is refined and made sure to serve the role, we can add to implement an LdapIdentityBackend using the ApacheDS LDAP server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-174) Common test utility for all kinds of identity backends
Kai Zheng created DIRKRB-174: Summary: Common test utility for all kinds of identity backends Key: DIRKRB-174 URL: https://issues.apache.org/jira/browse/DIRKRB-174 Project: Directory Kerberos Issue Type: Test Reporter: Kai Zheng Assignee: Kai Zheng It will be good to have common test utility to ease writing tests in various identity backends. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14361626#comment-14361626 ] Kai Zheng commented on DIRKRB-109: -- Hi [~pfm.smits], bq.Good suggestion, Emmanuel. I thought the same. It would be great we have more options. Thanks any potential contribution. bq.But before we start that, we should ask ourselves what kind of values do we want to instill with the logo... IMHO, it would be good or at least not bad if it can connect with the simple position of the project, another Kerberos implementation in Java, or a kid of Kerberos. We may build more, but the base is Kerberos, 3-headed dog. bq.This issue is a good place to get those on the table. I agree. It's good to put and discuss all the options here. In the end, in case we may have only one option in reasonable time, would you mind if I use it in my presentation or elsewhere when introduce the project, and see how others like it ? Regards, Kai We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Assignee: Emmanuel Lecharny Attachments: DIRKRB-109_v3.png, logo draft.png, logo with color.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358354#comment-14358354 ] Kai Zheng commented on DIRKRB-109: -- Hi Pierre, You just provided very good and valuable thought. Thank you so much. I thought the logo matches well with the project name Kerby, a kid of Kerberos, but as you said it may not match what some of us expect the project to be. I don't have idea how to balance it, so have a better and suitable one. Any idea how to adjust the logo ? Best regards, Kai We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Assignee: Emmanuel Lecharny Attachments: logo draft.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359791#comment-14359791 ] Kai Zheng commented on DIRKRB-109: -- Thanks [~HazelC] for taking this. It looks very cool ! We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Assignee: Emmanuel Lecharny Attachments: logo draft.png, logo with color.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-172) Working on a standalone KDC server
[ https://issues.apache.org/jira/browse/DIRKRB-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-172: Assignee: Kai Zheng Working on a standalone KDC server -- Key: DIRKRB-172 URL: https://issues.apache.org/jira/browse/DIRKRB-172 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We're working on a standalone KDC server, running, testing, and fixing. This is to track all the related issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-168) Adding a json file based identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-168: - Summary: Adding a json file based identity backend (was: Adding a json-based identity backend) Adding a json file based identity backend - Key: DIRKRB-168 URL: https://issues.apache.org/jira/browse/DIRKRB-168 Project: Directory Kerberos Issue Type: Sub-task Reporter: Lin Chen Adding a json-based identity backend for kdc server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-168) Adding a json file based identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359354#comment-14359354 ] Kai Zheng commented on DIRKRB-168: -- This is probably a most simple way to get a standalone server running first and fully functional. Adding a json file based identity backend - Key: DIRKRB-168 URL: https://issues.apache.org/jira/browse/DIRKRB-168 Project: Directory Kerberos Issue Type: Sub-task Reporter: Lin Chen Adding a json-based identity backend for kdc server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-168) Adding a json file based identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-168: Assignee: Kai Zheng Adding a json file based identity backend - Key: DIRKRB-168 URL: https://issues.apache.org/jira/browse/DIRKRB-168 Project: Directory Kerberos Issue Type: Sub-task Reporter: Lin Chen Assignee: Kai Zheng Adding a json-based identity backend for kdc server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-170) Kdc server will throw exceptions when a client closed
[ https://issues.apache.org/jira/browse/DIRKRB-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-170: Assignee: Kai Zheng Kdc server will throw exceptions when a client closed - Key: DIRKRB-170 URL: https://issues.apache.org/jira/browse/DIRKRB-170 Project: Directory Kerberos Issue Type: Improvement Reporter: Lin Chen Assignee: Kai Zheng When a client was closed, the kdc server will throw many exceptions constantly. Such as IOException: An existing connection was forcibly closed by the remote host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-171) No response to client when incorrect password
[ https://issues.apache.org/jira/browse/DIRKRB-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-171: Assignee: Kai Zheng No response to client when incorrect password - Key: DIRKRB-171 URL: https://issues.apache.org/jira/browse/DIRKRB-171 Project: Directory Kerberos Issue Type: Improvement Reporter: Lin Chen Assignee: Kai Zheng When client request a ticket from kdc server, client should input a password. If the password is incorrect, server will throw many exceptions but the client would not get any response about what's wrong. Maybe it is not very user-friendly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-172) Working on a standalone KDC server
Kai Zheng created DIRKRB-172: Summary: Working on a standalone KDC server Key: DIRKRB-172 URL: https://issues.apache.org/jira/browse/DIRKRB-172 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng We're working on a standalone KDC server, running, testing, and fixing. This is to track all the related issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-173) A Zookeeper based high performance identity backend
Kai Zheng created DIRKRB-173: Summary: A Zookeeper based high performance identity backend Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This will create a Zookeeper based identity backend targeting for high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-168) Adding a json file based identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-168: - Description: Adding a json-based identity backend for kdc server targeting for small, easy, development and test environment. (was: Adding a json-based identity backend for kdc server.) Adding a json file based identity backend - Key: DIRKRB-168 URL: https://issues.apache.org/jira/browse/DIRKRB-168 Project: Directory Kerberos Issue Type: Sub-task Reporter: Lin Chen Assignee: Kai Zheng Adding a json-based identity backend for kdc server targeting for small, easy, development and test environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-173) A Zookeeper based high reliable performance identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-173: - Summary: A Zookeeper based high reliable performance identity backend (was: A Zookeeper based high performance identity backend) A Zookeeper based high reliable performance identity backend -- Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This will create a Zookeeper based identity backend targeting for high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-173) A Zookeeper based high reliable performance identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-173: - Description: This will create a Zookeeper based identity backend targeting for high reliable and high performance requirement and scenarios. (was: This will create a Zookeeper based identity backend targeting for high performance requirement and scenarios.) A Zookeeper based high reliable performance identity backend -- Key: DIRKRB-173 URL: https://issues.apache.org/jira/browse/DIRKRB-173 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This will create a Zookeeper based identity backend targeting for high reliable and high performance requirement and scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-167) Create a tools container module in top level for all kinds of Kerby KDC tools
Kai Zheng created DIRKRB-167: Summary: Create a tools container module in top level for all kinds of Kerby KDC tools Key: DIRKRB-167 URL: https://issues.apache.org/jira/browse/DIRKRB-167 Project: Directory Kerberos Issue Type: Task Reporter: Kai Zheng Assignee: Kai Zheng This is to Create a tools container module in top level for all kinds of Kerby KDC tools. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-167) Create a tools container module in top level for all kinds of Kerby KDC tools
[ https://issues.apache.org/jira/browse/DIRKRB-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-167. -- Resolution: Fixed commit 2d36679053ec82afe0802802144cc10a94797bb3 Author: Drankye dran...@gmail.com Date: Thu Mar 12 05:17:27 2015 +0800 DIRKRB-167 Create a tools container module in top level for all kinds of Kerby KDC tools Create a tools container module in top level for all kinds of Kerby KDC tools - Key: DIRKRB-167 URL: https://issues.apache.org/jira/browse/DIRKRB-167 Project: Directory Kerberos Issue Type: Task Reporter: Kai Zheng Assignee: Kai Zheng This is to Create a tools container module in top level for all kinds of Kerby KDC tools. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-160) Packing related jars as Kerberos client library for applications
[ https://issues.apache.org/jira/browse/DIRKRB-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-160. -- Resolution: Fixed It's well done, thanks ! Packing related jars as Kerberos client library for applications Key: DIRKRB-160 URL: https://issues.apache.org/jira/browse/DIRKRB-160 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen To ease applications to use the Kerberos client library, it's good to provide one or two single jars by incorporating related jars together, since we have quite a few of modules and they're hard for normal users to select from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-161) Packing related jars as Kerberos server library for applications
[ https://issues.apache.org/jira/browse/DIRKRB-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-161. -- Resolution: Fixed It's well done, thanks ! Packing related jars as Kerberos server library for applications Key: DIRKRB-161 URL: https://issues.apache.org/jira/browse/DIRKRB-161 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen To ease applications to use the Kerberos server library, it's good to provide one or two jars by incorporating related jars together, since we have quite a few of modules and they're hard for normal users to select from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-134. -- Resolution: Fixed I just merged this into master branch and we can continue to improve the work as follow up issues. Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357856#comment-14357856 ] Kai Zheng commented on DIRKRB-109: -- I agree. I thought Lin has a very good understanding of the project. It's a Kerberos one, but cute and nice. Back to Kiran's concern, do we need a sleepy head ? We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Assignee: Emmanuel Lecharny Attachments: logo draft.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-109) We need a logo for the subproject
[ https://issues.apache.org/jira/browse/DIRKRB-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14356955#comment-14356955 ] Kai Zheng commented on DIRKRB-109: -- Yes it's pretty cute. As a three-heads animal, should the three heads behave the same or differently ? We don't expect any head to be sleepy ? If so, not sleepy at all for each head, then what effect would be ? We need a logo for the subproject - Key: DIRKRB-109 URL: https://issues.apache.org/jira/browse/DIRKRB-109 Project: Directory Kerberos Issue Type: Sub-task Reporter: Pierre Smits Assignee: Emmanuel Lecharny Attachments: logo draft.png The logo should preferably be of size 125 x 125 pixels in order to use it also as web ads (IAB standards). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-169) Adding a default identity in memory identity backend
[ https://issues.apache.org/jira/browse/DIRKRB-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358014#comment-14358014 ] Kai Zheng commented on DIRKRB-169: -- I thought we need to remove the test account once when we have relevant tool like kadmin to create principals for the KDC server. Adding a default identity in memory identity backend Key: DIRKRB-169 URL: https://issues.apache.org/jira/browse/DIRKRB-169 Project: Directory Kerberos Issue Type: Improvement Reporter: Lin Chen Adding a default identity in memory identity backend for test. In future, it will be improved in DIRKRB-168. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-165) Bypass AES256 test cases on platform doesn't have AES256 enabled
[
https://issues.apache.org/jira/browse/DIRKRB-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14351998#comment-14351998
]
Kai Zheng commented on DIRKRB-165:
--
Thanks [~yiliqi] for contributing this ! I looked at the patch, it looks great.
A mistake was noted for Camillia256, not AES256. Please correct, thanks !
{code}
@Test
public void testCamellia256() throws IOException, KrbException {
+if(!EncryptionHandler.isAES256Enabled()) {
+return;
+}
+
testEncWith(camellia256-cts-cmac.cc);
}
{code}
Bypass AES256 test cases on platform doesn't have AES256 enabled
Key: DIRKRB-165
URL: https://issues.apache.org/jira/browse/DIRKRB-165
Project: Directory Kerberos
Issue Type: Test
Environment: centos 6.6, oracle jdk 1.7 u60
Reporter: Liqi Yi
Attachments: DIRKRB-165.001.patch
Original Estimate: 24h
Remaining Estimate: 24h
On platforms that do not have AES256 enabled, the AES256 test cases would
fail with illegal key size exception. It would be nice to bypass these tests
when AES256 is not supported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (DIRKRB-164) Refactor and split KeyDeriveTest
[ https://issues.apache.org/jira/browse/DIRKRB-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-164. -- Resolution: Fixed Reviewed and committed. Thanks Liqi for the contribution ! commit c04f55323f3874055854f0d6e6ca9ee517885432 Author: Drankye dran...@gmail.com Date: Sun Mar 8 02:04:58 2015 +0800 DIRKRB-164 Refactor and split KeyDeriveTest. Contributed by Liqi Refactor and split KeyDeriveTest Key: DIRKRB-164 URL: https://issues.apache.org/jira/browse/DIRKRB-164 Project: Directory Kerberos Issue Type: Test Reporter: Liqi Yi Attachments: DIRKRB-164.001.patch Original Estimate: 24h Remaining Estimate: 24h -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-127) Implementing the TokenPreauth Access Token profile
[ https://issues.apache.org/jira/browse/DIRKRB-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-127: - Summary: Implementing the TokenPreauth Access Token profile (was: Implementing the token-preauth Access Token profile) Implementing the TokenPreauth Access Token profile -- Key: DIRKRB-127 URL: https://issues.apache.org/jira/browse/DIRKRB-127 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This is to implement the Access Token profile based on the token-preauth mechanism defined in the draft. Ref. docs/accesstoken-profile.pdf. The resultant work is only for experimental usage can only be promoted for production when the draft is finally passed. Currently we're collaborating with MIT Kerberos team discussing thru the spec but due to the low priority it's running very slow. By this implementation and possible POCs good experience can be obtained as feedback to refine the draft. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-128) KrbClient supports both TCP and UDP, trying TCP first
[ https://issues.apache.org/jira/browse/DIRKRB-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-128: Assignee: Kai Zheng KrbClient supports both TCP and UDP, trying TCP first - Key: DIRKRB-128 URL: https://issues.apache.org/jira/browse/DIRKRB-128 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng With the mixing support of TCP and UDP provided by haox-event, this is to allow KrbClient to support the both protocols with TCP being tried first according to latest Kerberos spec. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-161) Packing related jars as Kerberos server library for applications
[ https://issues.apache.org/jira/browse/DIRKRB-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14351832#comment-14351832 ] Kai Zheng commented on DIRKRB-161: -- Hi [~HazelC], Thanks for working on this. Is it possible to get this in master first ? Note it's only for library level, on server side, not necessarily related to standalone service. Maybe we can have a new module for this in kerby-kerb module. Packing related jars as Kerberos server library for applications Key: DIRKRB-161 URL: https://issues.apache.org/jira/browse/DIRKRB-161 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen To ease applications to use the Kerberos server library, it's good to provide one or two jars by incorporating related jars together, since we have quite a few of modules and they're hard for normal users to select from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-128) KrbClient supports both TCP and UDP, trying TCP first
[ https://issues.apache.org/jira/browse/DIRKRB-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-128. -- Resolution: Fixed commit daa4ba59ca62f840880d6f4de46bcdb270a44d67 Author: Drankye dran...@gmail.com Date: Sun Mar 8 09:00:39 2015 +0800 DIRKRB-128 KrbClient supports both TCP and UDP, trying TCP first KrbClient supports both TCP and UDP, trying TCP first - Key: DIRKRB-128 URL: https://issues.apache.org/jira/browse/DIRKRB-128 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng With the mixing support of TCP and UDP provided by haox-event, this is to allow KrbClient to support the both protocols with TCP being tried first according to latest Kerberos spec. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-163) align package declearation and real path for Kinit.java
[ https://issues.apache.org/jira/browse/DIRKRB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14341782#comment-14341782 ] Kai Zheng commented on DIRKRB-163: -- Reviewed and committed. Thanks Liqi ! commit 3c5179ad58e703707eead08798bd93461453 Author: Drankye dran...@gmail.com Date: Sun Mar 1 13:06:46 2015 +0800 DIRKRB-163 align package declearation and real path for Kinit.java. Contributed by Liqi align package declearation and real path for Kinit.java --- Key: DIRKRB-163 URL: https://issues.apache.org/jira/browse/DIRKRB-163 Project: Directory Kerberos Issue Type: Improvement Affects Versions: 2.0.0-M16 Reporter: Liqi Yi Priority: Trivial Labels: newbie Attachments: DIRKRB-163.patch Original Estimate: 1m Remaining Estimate: 1m package declearation for tool/src/main/java/org/apache/kerberos/tool/Kinit.java is org.apache.kerby.kerberos.tool which two do not match, reported by eclipse. moving Kinit.java to tool/src/main/java/org/apache/kerby/kerberos/tool/ would solve the confliction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-163) align package declearation and real path for Kinit.java
[ https://issues.apache.org/jira/browse/DIRKRB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-163. -- Resolution: Fixed align package declearation and real path for Kinit.java --- Key: DIRKRB-163 URL: https://issues.apache.org/jira/browse/DIRKRB-163 Project: Directory Kerberos Issue Type: Improvement Affects Versions: 2.0.0-M16 Reporter: Liqi Yi Priority: Trivial Labels: newbie Attachments: DIRKRB-163.patch Original Estimate: 1m Remaining Estimate: 1m package declearation for tool/src/main/java/org/apache/kerberos/tool/Kinit.java is org.apache.kerby.kerberos.tool which two do not match, reported by eclipse. moving Kinit.java to tool/src/main/java/org/apache/kerby/kerberos/tool/ would solve the confliction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DIRKRB-163) align package declearation and real path for Kinit.java
[ https://issues.apache.org/jira/browse/DIRKRB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339950#comment-14339950 ] Kai Zheng edited comment on DIRKRB-163 at 2/27/15 8:22 PM: --- Good catch, [~yiliqi]. Thanks ! was (Author: drankye): Good catch, [~liqi6510]. Thanks ! align package declearation and real path for Kinit.java --- Key: DIRKRB-163 URL: https://issues.apache.org/jira/browse/DIRKRB-163 Project: Directory Kerberos Issue Type: Improvement Affects Versions: 2.0.0-M16 Reporter: Liqi Yi Priority: Trivial Labels: newbie Original Estimate: 1m Remaining Estimate: 1m package declearation for tool/src/main/java/org/apache/kerberos/tool/Kinit.java is org.apache.kerby.kerberos.tool which two do not match, reported by eclipse. moving Kinit.java to tool/src/main/java/org/apache/kerby/kerberos/tool/ would solve the confliction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-163) align package declearation and real path for Kinit.java
[ https://issues.apache.org/jira/browse/DIRKRB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-163: - Component/s: (was: changepw) align package declearation and real path for Kinit.java --- Key: DIRKRB-163 URL: https://issues.apache.org/jira/browse/DIRKRB-163 Project: Directory Kerberos Issue Type: Improvement Affects Versions: 2.0.0-M16 Reporter: Liqi Yi Priority: Trivial Labels: newbie Original Estimate: 1m Remaining Estimate: 1m package declearation for tool/src/main/java/org/apache/kerberos/tool/Kinit.java is org.apache.kerby.kerberos.tool which two do not match, reported by eclipse. moving Kinit.java to tool/src/main/java/org/apache/kerby/kerberos/tool/ would solve the confliction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-163) align package declearation and real path for Kinit.java
[ https://issues.apache.org/jira/browse/DIRKRB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339950#comment-14339950 ] Kai Zheng commented on DIRKRB-163: -- Good catch, [~liqi6510]. Thanks ! align package declearation and real path for Kinit.java --- Key: DIRKRB-163 URL: https://issues.apache.org/jira/browse/DIRKRB-163 Project: Directory Kerberos Issue Type: Improvement Affects Versions: 2.0.0-M16 Reporter: Liqi Yi Priority: Trivial Labels: newbie Original Estimate: 1m Remaining Estimate: 1m package declearation for tool/src/main/java/org/apache/kerberos/tool/Kinit.java is org.apache.kerby.kerberos.tool which two do not match, reported by eclipse. moving Kinit.java to tool/src/main/java/org/apache/kerby/kerberos/tool/ would solve the confliction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-160) Packing related jars as Kerberos client library for applications
Kai Zheng created DIRKRB-160: Summary: Packing related jars as Kerberos client library for applications Key: DIRKRB-160 URL: https://issues.apache.org/jira/browse/DIRKRB-160 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng To ease applications to use the Kerberos client library, it's good to provide one or two single jars by incorporating related jars together, since we have quite a few of modules and they're hard for normal users to select from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-161) Packing related jars as Kerberos server library for applications
Kai Zheng created DIRKRB-161: Summary: Packing related jars as Kerberos server library for applications Key: DIRKRB-161 URL: https://issues.apache.org/jira/browse/DIRKRB-161 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng To ease applications to use the Kerberos server library, it's good to provide one or two jars by incorporating related jars together, since we have quite a few of modules and they're hard for normal users to select from. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317688#comment-14317688 ] Kai Zheng commented on DIRKRB-134: -- Hi [~HazelC], bq.Do you think which way is better? I would prefer to your approach, by selecting one by one. This is obvious because once we get DIRKRB-160 and DIRKRB-161 done, only very limited jars are to be collected for the installation package. bq.then change the working dir path in configuration file. It looks to me not good to have to change the working directory after installed but before launching. Let me think about this later. Thanks. Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-102) [Apache Kerby] A dedicated Kerberos project
[ https://issues.apache.org/jira/browse/DIRKRB-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-102: - Summary: [Apache Kerby] A dedicated Kerberos project (was: A dedicated Kerberos project ) [Apache Kerby] A dedicated Kerberos project Key: DIRKRB-102 URL: https://issues.apache.org/jira/browse/DIRKRB-102 Project: Directory Kerberos Issue Type: New Feature Reporter: Kai Zheng Labels: Kerberos As discussed in the community, we're going to create a dedicated Kerberos project based on Haox project codebase (https://github.com/drankye/haox) incorporating and consolidating the existing Kerberos functionalities in ApacheDS. The long term goal is to establish a first class Kerberos implementation in Java for the Apache world targeting today's environments in cloud, Hadoop and mobile. It will provides rich, intuitive and interoperable library and facilities that integrate multiple authentication mechanisms including PKI, OTP and token (OAuth) as desired in above mentioned modern environments.It will also implement a KDC server that can integrate various identity back ends including simple memory database, SQL database and LDAP server by dynamic plugin and loading approach, which allows it to be utilized in various contexts and scenarios. This serves as the master JIRA to track all the related tasks for the new sub project. With the fundamental aspects and tasks resolved, we would go to next phase targeting an Apache TLP project, as we agreed in the discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-149) Re-organize the project layout with the new name 'Apache Kerby'
[ https://issues.apache.org/jira/browse/DIRKRB-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-149. -- Resolution: Fixed Let's resolve this as no further feedback so far. Re-organize the project layout with the new name 'Apache Kerby' --- Key: DIRKRB-149 URL: https://issues.apache.org/jira/browse/DIRKRB-149 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We just decided to use the new name 'Apache Kerby', which requires to rename the modules, generally like replacing 'Haox' with 'Kerby'. Kiran also proposed many great ideas about how to layout the whole project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313188#comment-14313188 ] Kai Zheng commented on DIRKRB-134: -- Hi [~HazelC], I played some while with it. It's a great starting step. Thanks ! Let's improve this based on the branch, when it works perfectly, we'll merge this to master. Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313191#comment-14313191 ] Kai Zheng commented on DIRKRB-134: -- I noticed test related jars are also copied there. Could you improve and avoid that ? If not possible, we may have a post step when packaging to remove those jars. Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313192#comment-14313192 ] Kai Zheng commented on DIRKRB-134: -- Another point is, could we have an installation package like a tar ball (*.tgz), with something like HowToInstall.txt included without any relying on the building developing working folder ? Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-146) Test for encrypted data in Kerberos message
[ https://issues.apache.org/jira/browse/DIRKRB-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313150#comment-14313150 ] Kai Zheng commented on DIRKRB-146: -- Yes [~HazelC], I will look at this. Thanks for finding the issue ! Test for encrypted data in Kerberos message --- Key: DIRKRB-146 URL: https://issues.apache.org/jira/browse/DIRKRB-146 Project: Directory Kerberos Issue Type: Test Reporter: Lin Chen Assignee: Lin Chen Test for encrypted data in Kerberos message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-145) Add tests for Asn1GeneralizedTime type
[ https://issues.apache.org/jira/browse/DIRKRB-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14311831#comment-14311831 ] Kai Zheng commented on DIRKRB-145: -- [~zhouwei] would help with this one. Thanks. Add tests for Asn1GeneralizedTime type -- Key: DIRKRB-145 URL: https://issues.apache.org/jira/browse/DIRKRB-145 Project: Directory Kerberos Issue Type: Test Reporter: Lin Chen Assignee: Kai Zheng Add tests for Asn1GeneralizedTime type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-145) Add tests for Asn1GeneralizedTime type
[ https://issues.apache.org/jira/browse/DIRKRB-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-145: Assignee: Kai Zheng Add tests for Asn1GeneralizedTime type -- Key: DIRKRB-145 URL: https://issues.apache.org/jira/browse/DIRKRB-145 Project: Directory Kerberos Issue Type: Test Reporter: Lin Chen Assignee: Kai Zheng Add tests for Asn1GeneralizedTime type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng resolved DIRKRB-158.
--
Resolution: Fixed
Decouple the mixed aspects in EncodingOption in kerby-asn1
--
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a
mixture of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be
better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them.
It's good to have specific field for each of the aspects as you listed,
marked as 'private',
and providing 'public' get methods to them, and in codes we use the methods
instead of those fields.
In some future we can optimize these fields out using a bit vector or an int
to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng reassigned DIRKRB-158:
Assignee: Kai Zheng
Decouple the mixed aspects in EncodingOption in kerby-asn1
--
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Assignee: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a
mixture of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be
better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them.
It's good to have specific field for each of the aspects as you listed,
marked as 'private',
and providing 'public' get methods to them, and in codes we use the methods
instead of those fields.
In some future we can optimize these fields out using a bit vector or an int
to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14311795#comment-14311795
]
Kai Zheng commented on DIRKRB-158:
--
commit 57e75f088d489b37f8480924cbb83d58ccdc24a4
Author: Drankye dran...@gmail.com
Date: Mon Feb 9 11:13:08 2015 +0800
DIRKRB-158. Decouple the mixed aspects in EncodingOption in kerby-asn1
Decouple the mixed aspects in EncodingOption in kerby-asn1
--
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a
mixture of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be
better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them.
It's good to have specific field for each of the aspects as you listed,
marked as 'private',
and providing 'public' get methods to them, and in codes we use the methods
instead of those fields.
In some future we can optimize these fields out using a bit vector or an int
to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRKRB-108) Building the web site
[ https://issues.apache.org/jira/browse/DIRKRB-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308691#comment-14308691 ] Kai Zheng commented on DIRKRB-108: -- I'm sorry for delaying on this, crazy busy with other projects, but will have to get my part done the weekend. Building the web site - Key: DIRKRB-108 URL: https://issues.apache.org/jira/browse/DIRKRB-108 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to build the new website for this new Kerberos project, as we did for other sub projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-159) Having a decoartor for each type of encoding, like BER/CER/DER
[
https://issues.apache.org/jira/browse/DIRKRB-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308722#comment-14308722
]
Kai Zheng commented on DIRKRB-159:
--
Logging this in case it's forgotten. We should consider this in the future when
have the bandwidth.
Having a decoartor for each type of encoding, like BER/CER/DER
--
Key: DIRKRB-159
URL: https://issues.apache.org/jira/browse/DIRKRB-159
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, giving the thoughts:
{noformat}
we do the encoding/decoding in the ASN1 type instances.
That's ok, but as soon as we have to deal with various type of encoding
(BER/CER...) this cipple the code with if/else/then.
What about having a decoartor for each type of encoding ?
{noformat}
Below is [~drankye]'s response in email:
{noformat}
I agree. If we're going to support BER and DER both well or new schemes,
then we need such. It won't introduce API change for the types and is only
for internal encoding/decoding implementation, right ?
Could you have a simple illustration or example,
say how to do that for the simple Asn1Boolean type ? Thanks.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
Kai Zheng created DIRKRB-158:
Summary: Decouple the mixed aspects in EncodingOption in kerby-asn1
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a mixture
of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values (CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects.
We should divide them. It's good to have specific field for each of the aspects
as you listed,
marked as 'private', and providing 'public' get methods to them,
and in codes we use the methods instead of those fields.
In some future we can optimize these fields out using a bit vector or
an int to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DIRKRB-159) Having a decoartor for each type (like BER/CER/DER) of encoding
[
https://issues.apache.org/jira/browse/DIRKRB-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng updated DIRKRB-159:
-
Summary: Having a decoartor for each type (like BER/CER/DER) of encoding
(was: Having a decoartor for each type of encoding, like BER/CER/DER)
Having a decoartor for each type (like BER/CER/DER) of encoding
---
Key: DIRKRB-159
URL: https://issues.apache.org/jira/browse/DIRKRB-159
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, giving the thoughts:
{noformat}
we do the encoding/decoding in the ASN1 type instances.
That's ok, but as soon as we have to deal with various type of encoding
(BER/CER...) this cipple the code with if/else/then.
What about having a decoartor for each type of encoding ?
{noformat}
Below is [~drankye]'s response in email:
{noformat}
I agree. If we're going to support BER and DER both well or new schemes,
then we need such. It won't introduce API change for the types and is only
for internal encoding/decoding implementation, right ?
Could you have a simple illustration or example,
say how to do that for the simple Asn1Boolean type ? Thanks.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng updated DIRKRB-158:
-
Description:
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a mixture
of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values (CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them. It's good to have specific field for each of the aspects as you
listed, marked as 'private', and providing 'public' get methods to them, and in
codes we use the methods instead of those fields. In some future we can
optimize these fields out using a bit vector or an int to flag them.
{noformat}
was:
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a mixture
of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values (CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects.
We should divide them. It's good to have specific field for each of the aspects
as you listed,
marked as 'private', and providing 'public' get methods to them,
and in codes we use the methods instead of those fields.
In some future we can optimize these fields out using a bit vector or
an int to flag them.
{noformat}
Decouple the mixed aspects in EncodingOption in kerby-asn1
--
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a
mixture of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values (CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be
better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them. It's good to have specific field for each of the aspects as you
listed, marked as 'private', and providing 'public' get methods to them, and
in codes we use the methods instead of those fields. In some future we can
optimize these fields out using a bit vector or an int to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DIRKRB-159) Having a decoartor for each type of encoding, like BER/CER/DER
Kai Zheng created DIRKRB-159:
Summary: Having a decoartor for each type of encoding, like
BER/CER/DER
Key: DIRKRB-159
URL: https://issues.apache.org/jira/browse/DIRKRB-159
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, giving the thoughts:
{noformat}
we do the encoding/decoding in the ASN1 type instances.
That's ok, but as soon as we have to deal with various type of encoding
(BER/CER...) this cipple the code with if/else/then.
What about having a decoartor for each type of encoding ?
{noformat}
Below is [~drankye]'s response in email:
{noformat}
I agree. If we're going to support BER and DER both well or new schemes,
then we need such. It won't introduce API change for the types and is only
for internal encoding/decoding implementation, right ?
Could you have a simple illustration or example,
say how to do that for the simple Asn1Boolean type ? Thanks.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRKRB-108) Building the web site
[ https://issues.apache.org/jira/browse/DIRKRB-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308735#comment-14308735 ] Kai Zheng commented on DIRKRB-108: -- bq.The web site is entirely stored in http://svn.apache.org/viewvc/directory/site/ When check it out using svn, should use this url: https://svn.apache.org/repos/asf/directory/site/trunk/ Building the web site - Key: DIRKRB-108 URL: https://issues.apache.org/jira/browse/DIRKRB-108 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to build the new website for this new Kerberos project, as we did for other sub projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308713#comment-14308713
]
Kai Zheng commented on DIRKRB-158:
--
Logging this great idea for future's consideration when having the time.
Decouple the mixed aspects in EncodingOption in kerby-asn1
--
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a
mixture of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be
better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them.
It's good to have specific field for each of the aspects as you listed,
marked as 'private',
and providing 'public' get methods to them, and in codes we use the methods
instead of those fields.
In some future we can optimize these fields out using a bit vector or an int
to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DIRKRB-158) Decouple the mixed aspects in EncodingOption in kerby-asn1
[
https://issues.apache.org/jira/browse/DIRKRB-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai Zheng updated DIRKRB-158:
-
Description:
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a mixture
of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them.
It's good to have specific field for each of the aspects as you listed, marked
as 'private',
and providing 'public' get methods to them, and in codes we use the methods
instead of those fields.
In some future we can optimize these fields out using a bit vector or an int to
flag them.
{noformat}
was:
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a mixture
of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values (CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them. It's good to have specific field for each of the aspects as you
listed, marked as 'private', and providing 'public' get methods to them, and in
codes we use the methods instead of those fields. In some future we can
optimize these fields out using a bit vector or an int to flag them.
{noformat}
Decouple the mixed aspects in EncodingOption in kerby-asn1
--
Key: DIRKRB-158
URL: https://issues.apache.org/jira/browse/DIRKRB-158
Project: Directory Kerberos
Issue Type: Improvement
Reporter: Kai Zheng
Below is from [~elecharny]'s email, proposing his thoughts:
{noformat}
just looking at the EncodingOption enum, and I wonder if there is not a
mixture of things in it.
Typically, we have some encoding type like BER/CER/DER, mixed with other
unrelated values
(CONSTRUCTED/PRIMITIVE/IMPLICIT/EXPLICIT).
I understand that it's used to gather multiple flags into one enum, but
- it's not clear from a programmer POV
- you can't tranlate that easily without adding many explicit methods in the
enum (isConstructed(), etc...)
I wonder if using a specifig field for each of those flags would not be
better ?
Something like :
public abstract class AbstractAsn1TypeT implements Asn1Type {
private boolean pc// Primitive/constructed
private boolean lengthType; // Definite/Undefinite
private EncodingType encoding; // BER/CER/DER/XER/PER
...
{noformat}
And [~drankye]'s email response:
{noformat}
I agree. EncodingOption is a dirty work and mixes too many aspects. We should
divide them.
It's good to have specific field for each of the aspects as you listed,
marked as 'private',
and providing 'public' get methods to them, and in codes we use the methods
instead of those fields.
In some future we can optimize these fields out using a bit vector or an int
to flag them.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRKRB-104) Clean up and clear the codes, clarifying any IP concerned codes
[ https://issues.apache.org/jira/browse/DIRKRB-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300757#comment-14300757 ] Kai Zheng commented on DIRKRB-104: -- I have gone through the codes and performed quit much clean up: 1. In kerb-crypto module, reimplemented some codes like des keymaker; 2. In not-commons-ssl library, getting rid of much redundant codes like ASN1 parsers; 3. In kerb-core-test, removed most of the codes from jaaslounge, and Lin has added some codec tests; 4. Also checked some codes in other modules. Clean up and clear the codes, clarifying any IP concerned codes --- Key: DIRKRB-104 URL: https://issues.apache.org/jira/browse/DIRKRB-104 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This is going to clean up and clear any IP and license related or concerned codes imported from Haox project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-104) Clean up and clear the codes, clarifying any IP concerned codes
[ https://issues.apache.org/jira/browse/DIRKRB-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-104. -- Resolution: Fixed Clean up and clear the codes, clarifying any IP concerned codes --- Key: DIRKRB-104 URL: https://issues.apache.org/jira/browse/DIRKRB-104 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng This is going to clean up and clear any IP and license related or concerned codes imported from Haox project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-108) Building the web site
[ https://issues.apache.org/jira/browse/DIRKRB-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-108: Assignee: Kai Zheng (was: Emmanuel Lecharny) Building the web site - Key: DIRKRB-108 URL: https://issues.apache.org/jira/browse/DIRKRB-108 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to build the new website for this new Kerberos project, as we did for other sub projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-108) Building the web site
[ https://issues.apache.org/jira/browse/DIRKRB-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300760#comment-14300760 ] Kai Zheng commented on DIRKRB-108: -- I was frequently asked by some questions like can you tell me the web site ? when I introduce Apache Kerby. OK, let me address this. Is there any guide regarding how to add the web pages for a new sub-project in ApacheDS ? Thanks. Building the web site - Key: DIRKRB-108 URL: https://issues.apache.org/jira/browse/DIRKRB-108 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to build the new website for this new Kerberos project, as we did for other sub projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-108) Building the web site
[ https://issues.apache.org/jira/browse/DIRKRB-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300978#comment-14300978 ] Kai Zheng commented on DIRKRB-108: -- Thank you Emmanuel for your help and the bootstrap ! Building the web site - Key: DIRKRB-108 URL: https://issues.apache.org/jira/browse/DIRKRB-108 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to build the new website for this new Kerberos project, as we did for other sub projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-157) Value like 0x01 01 7F should not be decoded as TRUE with DER
[ https://issues.apache.org/jira/browse/DIRKRB-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-157. -- Resolution: Fixed commit 377814b2dcfda1192d77cab8705fe7c750384810 Author: Drankye dran...@gmail.com Date: Sun Feb 1 10:19:05 2015 +0800 DIRKRB-157 Value like 0x01 01 7F should not be decoded as TRUE with DER Value like 0x01 01 7F should not be decoded as TRUE with DER Key: DIRKRB-157 URL: https://issues.apache.org/jira/browse/DIRKRB-157 Project: Directory Kerberos Issue Type: Bug Reporter: Emmanuel Lecharny Assignee: Kai Zheng Priority: Minor In BER, any value different from 0x00 is decoded as TRUE for boolean. DER impose a restriction, 0xFF is the only acceptable value for TRUE, per X.690, 11.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRKRB-157) Value like 0x01 01 7F should not be decoded as TRUE with DER
[ https://issues.apache.org/jira/browse/DIRKRB-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng updated DIRKRB-157: - Summary: Value like 0x01 01 7F should not be decoded as TRUE with DER (was: Value like 0x01 01 7F should not be decoded as Boolean with DER) Value like 0x01 01 7F should not be decoded as TRUE with DER Key: DIRKRB-157 URL: https://issues.apache.org/jira/browse/DIRKRB-157 Project: Directory Kerberos Issue Type: Bug Reporter: Emmanuel Lecharny Priority: Minor In BER, any value different from 0x00 is decoded as TRUE for boolean. DER impose a restriction, 0xFF is the only acceptable value for TRUE, per X.690, 11.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-157) Value like 0x01 01 7F should not be decoded as Boolean with DER
[ https://issues.apache.org/jira/browse/DIRKRB-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300046#comment-14300046 ] Kai Zheng commented on DIRKRB-157: -- Did you mean this in kerby-asn1 module ? Will look at it. Thanks for reporting this. Value like 0x01 01 7F should not be decoded as Boolean with DER --- Key: DIRKRB-157 URL: https://issues.apache.org/jira/browse/DIRKRB-157 Project: Directory Kerberos Issue Type: Bug Reporter: Emmanuel Lecharny Priority: Minor In BER, any value different from 0x00 is decoded as TRUE for boolean. DER impose a restriction, 0xFF is the only acceptable value for TRUE, per X.690, 11.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DIRKRB-157) Value like 0x01 01 7F should not be decoded as TRUE with DER
[ https://issues.apache.org/jira/browse/DIRKRB-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng reassigned DIRKRB-157: Assignee: Kai Zheng Value like 0x01 01 7F should not be decoded as TRUE with DER Key: DIRKRB-157 URL: https://issues.apache.org/jira/browse/DIRKRB-157 Project: Directory Kerberos Issue Type: Bug Reporter: Emmanuel Lecharny Assignee: Kai Zheng Priority: Minor In BER, any value different from 0x00 is decoded as TRUE for boolean. DER impose a restriction, 0xFF is the only acceptable value for TRUE, per X.690, 11.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298150#comment-14298150 ] Kai Zheng commented on DIRKRB-134: -- If possible, I mean, if we we can avoid corrupting and affecting the functionality, we should add the header. Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296481#comment-14296481 ] Kai Zheng commented on DIRKRB-134: -- It's great Lin could commit. Thanks. Lin, would you commit this in a new branch so anybody like me can have a try with it easily ? Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen Attachments: DIRKRB-134_v1.patch, wrapper.conf, wrapper.stop.conf This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-134) Installation packaging and service wrapper
[ https://issues.apache.org/jira/browse/DIRKRB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293202#comment-14293202 ] Kai Zheng commented on DIRKRB-134: -- Sounds great ! Installation packaging and service wrapper -- Key: DIRKRB-134 URL: https://issues.apache.org/jira/browse/DIRKRB-134 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Lin Chen This is for having installation packaging and service wrapper for the KDC server. We can borrow the existing artifacts from Directory Server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRKRB-155) Add the missing Javadoc for kerby-asn1 module
Kai Zheng created DIRKRB-155: Summary: Add the missing Javadoc for kerby-asn1 module Key: DIRKRB-155 URL: https://issues.apache.org/jira/browse/DIRKRB-155 Project: Directory Kerberos Issue Type: Task Reporter: Kai Zheng Assignee: Kai Zheng Let me add the missing Javadocs for kerby-asn1 module when have some trivial time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRKRB-118) Get rid of the external dependency to not-so-commons-ssl library
[ https://issues.apache.org/jira/browse/DIRKRB-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291020#comment-14291020 ] Kai Zheng commented on DIRKRB-118: -- commit 0e835cdcaf717cc881c1920543272c38efbe75fe Author: Drankye dran...@gmail.com Date: Sun Jan 25 16:53:32 2015 +0800 Removed http related from not-commons-ssl library commit bc5c276eec622e36c3a0dc340692834ff13da8fe Author: Drankye dran...@gmail.com Date: Mon Jan 26 00:43:39 2015 +0800 Clean up not-commons-ssl library, removing many unwanted and not much relevant Get rid of the external dependency to not-so-commons-ssl library Key: DIRKRB-118 URL: https://issues.apache.org/jira/browse/DIRKRB-118 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to remove the external dependency to not-so-commons-library in order to avoid better maintain and any license concerns. Currently the library was used to load private keys from related openSSL keystores or formats. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DIRKRB-118) Get rid of the external dependency to not-so-commons-ssl library
[ https://issues.apache.org/jira/browse/DIRKRB-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kai Zheng resolved DIRKRB-118. -- Resolution: Fixed Get rid of the external dependency to not-so-commons-ssl library Key: DIRKRB-118 URL: https://issues.apache.org/jira/browse/DIRKRB-118 Project: Directory Kerberos Issue Type: Sub-task Reporter: Kai Zheng Assignee: Kai Zheng We need to remove the external dependency to not-so-commons-library in order to avoid better maintain and any license concerns. Currently the library was used to load private keys from related openSSL keystores or formats. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
