[jira] [Closed] (DIRKRB-773) jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);

2024-05-02 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-773.
--
Resolution: Incomplete

> jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);
> ---
>
> Key: DIRKRB-773
> URL: https://issues.apache.org/jira/browse/DIRKRB-773
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: scott.zhai
>Priority: Major
>
> {code}
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRSERVER-2387) Broken link on download page

2024-01-15 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2387.

Resolution: Fixed

It should be fixed now, thanks for reporting.

> Broken link on download page
> 
>
> Key: DIRSERVER-2387
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2387
> Project: Directory ApacheDS
>  Issue Type: Bug
>Reporter: Sebb
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> https://directory.apache.org/apacheds/download/download-archive.html
> The SHA256 links are broken, because the files don't exist.
> Please either provide the files or remove the links



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-738) Package name conflicts between sub-projects create problems with Java modules

2024-01-15 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-738:


[~sshikov] When you say it "exists", is it breaking something?

> Package name conflicts between sub-projects create problems with Java modules
> -
>
> Key: DIRKRB-738
> URL: https://issues.apache.org/jira/browse/DIRKRB-738
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Richard Feezel
>Priority: Major
>  Labels: patch
> Attachments: kerby-package-conflicts.patch
>
>
> Eclipse now flags as errors attempts to access classes contained in a package 
> that is declared in more than one Jar (module). The current Kerby code base 
> has problems with the "org.apache.kerby.kerberos.kerb" and "org.apache.kerby" 
> packages in this regard. The affected projects are kerb-common, kerby-util, 
> kerb-core, kerb-util, and mavibot-backend. My approach to addressing this is 
> to create project-specific packages and moving the classes from these problem 
> package names to the new, project-specific ones. These changes, of course, 
> impact all uses of these moved classes resulting in many changes throughout 
> the Kerby system.
> Also included in the attached patch is a modification to the call to the 
> sun.security.krb5.Credentials constructor in has.client.HasLoginModule() to 
> add values for the new parameters.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-767) data race when multi KrbClients visit KdcServer

2023-11-29 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-767.

Resolution: Fixed

> data race when multi KrbClients visit KdcServer
> ---
>
> Key: DIRKRB-767
> URL: https://issues.apache.org/jira/browse/DIRKRB-767
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: lujie
>Priority: Minor
> Fix For: 2.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> when KDCServer started, it will run a thread to check if has a client request 
> in
> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run() method.
> *server test code:* 
> {code:java}
> // server test code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.server.SimpleKdcServer;
> public class TestServer2 {
> public static void main(String[] args) throws KrbException {
> SimpleKdcServer simpleKdcServer = new SimpleKdcServer();
> simpleKdcServer.setKdcHost("0.0.0.0");
> simpleKdcServer.setKdcRealm("service.ws.apache.org");
> simpleKdcServer.setKdcTcpPort(12345);
> simpleKdcServer.setAllowUdp(true);
> simpleKdcServer.setKdcUdpPort(12346);
> simpleKdcServer.init();
> // Create principals
> String alice = "al...@service.ws.apache.org";
> String bob = "bob/service.ws.apache@service.ws.apache.org";
> //simpleKdcServer.set
> simpleKdcServer.createPrincipal(alice, "alice");
> simpleKdcServer.createPrincipal(bob,"bob");
> simpleKdcServer.start();
> }
> } {code}
> *client test Code*
> {code:java}
> // client test Code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.client.KrbClient;
> import org.apache.kerby.kerberos.kerb.client.KrbPkinitClient;
> import org.apache.kerby.kerberos.kerb.type.ticket.SgtTicket;
> import org.apache.kerby.kerberos.kerb.type.ticket.TgtTicket;
> public class TestClient3 {
> public static void main(String[] args) {
> for (int i = 0; i < 10; i++) {
> System.out.println(i);
> new Thread(()->{
> try {
> KrbClient client = new KrbClient();
> client.setKdcHost("0.0.0.0");
> client.setKdcTcpPort(12345);
> client.setKdcUdpPort(12346);
> client.setKdcRealm("TEST2.COM");
> client.init();
> TgtTicket tgt;
> SgtTicket tkt;
> tgt = client.requestTgt("al...@service.ws.apache.org", 
> "alice");
> tkt = client.requestSgt(tgt, 
> "bob/service.ws.apache@service.ws.apache.org");
> } catch (KrbException e) {
> }
> }).start();
> }
> }
> }
>  {code}
> *method : 
> org.apache.kerby.kerberos.kerb.server.preauth.pkinit.PkinitPreauth.initWith(KdcContext
>  kdcContext)*
> *In order to make the results more visible, I inserted several lines of code, 
> such as {{System.out.println()}} and {{{}Thread.sleep(new 
> Random().nextInt(10)){}}}. Please let me know if there are any syntax errors.*
> {code:java}
> public void initWith(KdcContext kdcContext) {
> super.initWith(kdcContext);
> PkinitKdcContext tmp = new PkinitKdcContext();
> tmp.realm = kdcContext.getKdcRealm();
> String pkinitIdentity = kdcContext.getConfig().getPkinitIdentity();
> tmp.identityOpts.setIdentity(pkinitIdentity);
> System.out.println("start::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> try {
> Thread.sleep(new Random().nextInt(10));
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> pkinitContexts.put(kdcContext.getKdcRealm(), tmp);
> System.out.println("end::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> }{code}
>  After run the server and client, we will get the part of result:
> {panel}
> start::pool-1-thread-6 35766 1688116403609
> start::pool-1-thread-4 35766 1688116403609
> end::pool-1-thread-6 35766 1688116403610
> start::pool-1-thread-1 35766 1688116403609
> start::pool-1-thread-9 35766 1688116403609
> start::pool-1-thread-2 35766 1688116403609
> start::pool-1-thread-7 35766 1688116403609
> start::pool-1-thread-5 35766 1688116403609
> start::pool-1-thread-3 35766 1688116403609
> start::pool-1-thread-10 35766 1688116403609
> start::pool-1-thread-8 35766 1688116403609
> end::pool-1-thread-5 35766 1688116403613
> end::pool-1-thread-2 35766 1688116403613
> end::pool-1-thread-4 

[jira] [Assigned] (DIRKRB-767) data race when multi KrbClients visit KdcServer

2023-11-29 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-767:
--

Assignee: Colm O hEigeartaigh

> data race when multi KrbClients visit KdcServer
> ---
>
> Key: DIRKRB-767
> URL: https://issues.apache.org/jira/browse/DIRKRB-767
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: lujie
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> when KDCServer started, it will run a thread to check if has a client request 
> in
> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run() method.
> *server test code:* 
> {code:java}
> // server test code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.server.SimpleKdcServer;
> public class TestServer2 {
> public static void main(String[] args) throws KrbException {
> SimpleKdcServer simpleKdcServer = new SimpleKdcServer();
> simpleKdcServer.setKdcHost("0.0.0.0");
> simpleKdcServer.setKdcRealm("service.ws.apache.org");
> simpleKdcServer.setKdcTcpPort(12345);
> simpleKdcServer.setAllowUdp(true);
> simpleKdcServer.setKdcUdpPort(12346);
> simpleKdcServer.init();
> // Create principals
> String alice = "al...@service.ws.apache.org";
> String bob = "bob/service.ws.apache@service.ws.apache.org";
> //simpleKdcServer.set
> simpleKdcServer.createPrincipal(alice, "alice");
> simpleKdcServer.createPrincipal(bob,"bob");
> simpleKdcServer.start();
> }
> } {code}
> *client test Code*
> {code:java}
> // client test Code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.client.KrbClient;
> import org.apache.kerby.kerberos.kerb.client.KrbPkinitClient;
> import org.apache.kerby.kerberos.kerb.type.ticket.SgtTicket;
> import org.apache.kerby.kerberos.kerb.type.ticket.TgtTicket;
> public class TestClient3 {
> public static void main(String[] args) {
> for (int i = 0; i < 10; i++) {
> System.out.println(i);
> new Thread(()->{
> try {
> KrbClient client = new KrbClient();
> client.setKdcHost("0.0.0.0");
> client.setKdcTcpPort(12345);
> client.setKdcUdpPort(12346);
> client.setKdcRealm("TEST2.COM");
> client.init();
> TgtTicket tgt;
> SgtTicket tkt;
> tgt = client.requestTgt("al...@service.ws.apache.org", 
> "alice");
> tkt = client.requestSgt(tgt, 
> "bob/service.ws.apache@service.ws.apache.org");
> } catch (KrbException e) {
> }
> }).start();
> }
> }
> }
>  {code}
> *method : 
> org.apache.kerby.kerberos.kerb.server.preauth.pkinit.PkinitPreauth.initWith(KdcContext
>  kdcContext)*
> *In order to make the results more visible, I inserted several lines of code, 
> such as {{System.out.println()}} and {{{}Thread.sleep(new 
> Random().nextInt(10)){}}}. Please let me know if there are any syntax errors.*
> {code:java}
> public void initWith(KdcContext kdcContext) {
> super.initWith(kdcContext);
> PkinitKdcContext tmp = new PkinitKdcContext();
> tmp.realm = kdcContext.getKdcRealm();
> String pkinitIdentity = kdcContext.getConfig().getPkinitIdentity();
> tmp.identityOpts.setIdentity(pkinitIdentity);
> System.out.println("start::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> try {
> Thread.sleep(new Random().nextInt(10));
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> pkinitContexts.put(kdcContext.getKdcRealm(), tmp);
> System.out.println("end::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> }{code}
>  After run the server and client, we will get the part of result:
> {panel}
> start::pool-1-thread-6 35766 1688116403609
> start::pool-1-thread-4 35766 1688116403609
> end::pool-1-thread-6 35766 1688116403610
> start::pool-1-thread-1 35766 1688116403609
> start::pool-1-thread-9 35766 1688116403609
> start::pool-1-thread-2 35766 1688116403609
> start::pool-1-thread-7 35766 1688116403609
> start::pool-1-thread-5 35766 1688116403609
> start::pool-1-thread-3 35766 1688116403609
> start::pool-1-thread-10 35766 1688116403609
> start::pool-1-thread-8 35766 1688116403609
> end::pool-1-thread-5 35766 1688116403613
> 

[jira] [Updated] (DIRKRB-767) data race when multi KrbClients visit KdcServer

2023-11-29 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-767:
---
Priority: Minor  (was: Critical)

> data race when multi KrbClients visit KdcServer
> ---
>
> Key: DIRKRB-767
> URL: https://issues.apache.org/jira/browse/DIRKRB-767
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: lujie
>Priority: Minor
>
> when KDCServer started, it will run a thread to check if has a client request 
> in
> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run() method.
> *server test code:* 
> {code:java}
> // server test code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.server.SimpleKdcServer;
> public class TestServer2 {
> public static void main(String[] args) throws KrbException {
> SimpleKdcServer simpleKdcServer = new SimpleKdcServer();
> simpleKdcServer.setKdcHost("0.0.0.0");
> simpleKdcServer.setKdcRealm("service.ws.apache.org");
> simpleKdcServer.setKdcTcpPort(12345);
> simpleKdcServer.setAllowUdp(true);
> simpleKdcServer.setKdcUdpPort(12346);
> simpleKdcServer.init();
> // Create principals
> String alice = "al...@service.ws.apache.org";
> String bob = "bob/service.ws.apache@service.ws.apache.org";
> //simpleKdcServer.set
> simpleKdcServer.createPrincipal(alice, "alice");
> simpleKdcServer.createPrincipal(bob,"bob");
> simpleKdcServer.start();
> }
> } {code}
> *client test Code*
> {code:java}
> // client test Code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.client.KrbClient;
> import org.apache.kerby.kerberos.kerb.client.KrbPkinitClient;
> import org.apache.kerby.kerberos.kerb.type.ticket.SgtTicket;
> import org.apache.kerby.kerberos.kerb.type.ticket.TgtTicket;
> public class TestClient3 {
> public static void main(String[] args) {
> for (int i = 0; i < 10; i++) {
> System.out.println(i);
> new Thread(()->{
> try {
> KrbClient client = new KrbClient();
> client.setKdcHost("0.0.0.0");
> client.setKdcTcpPort(12345);
> client.setKdcUdpPort(12346);
> client.setKdcRealm("TEST2.COM");
> client.init();
> TgtTicket tgt;
> SgtTicket tkt;
> tgt = client.requestTgt("al...@service.ws.apache.org", 
> "alice");
> tkt = client.requestSgt(tgt, 
> "bob/service.ws.apache@service.ws.apache.org");
> } catch (KrbException e) {
> }
> }).start();
> }
> }
> }
>  {code}
> *method : 
> org.apache.kerby.kerberos.kerb.server.preauth.pkinit.PkinitPreauth.initWith(KdcContext
>  kdcContext)*
> *In order to make the results more visible, I inserted several lines of code, 
> such as {{System.out.println()}} and {{{}Thread.sleep(new 
> Random().nextInt(10)){}}}. Please let me know if there are any syntax errors.*
> {code:java}
> public void initWith(KdcContext kdcContext) {
> super.initWith(kdcContext);
> PkinitKdcContext tmp = new PkinitKdcContext();
> tmp.realm = kdcContext.getKdcRealm();
> String pkinitIdentity = kdcContext.getConfig().getPkinitIdentity();
> tmp.identityOpts.setIdentity(pkinitIdentity);
> System.out.println("start::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> try {
> Thread.sleep(new Random().nextInt(10));
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> pkinitContexts.put(kdcContext.getKdcRealm(), tmp);
> System.out.println("end::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> }{code}
>  After run the server and client, we will get the part of result:
> {panel}
> start::pool-1-thread-6 35766 1688116403609
> start::pool-1-thread-4 35766 1688116403609
> end::pool-1-thread-6 35766 1688116403610
> start::pool-1-thread-1 35766 1688116403609
> start::pool-1-thread-9 35766 1688116403609
> start::pool-1-thread-2 35766 1688116403609
> start::pool-1-thread-7 35766 1688116403609
> start::pool-1-thread-5 35766 1688116403609
> start::pool-1-thread-3 35766 1688116403609
> start::pool-1-thread-10 35766 1688116403609
> start::pool-1-thread-8 35766 1688116403609
> end::pool-1-thread-5 35766 1688116403613
> end::pool-1-thread-2 35766 1688116403613
> end::pool-1-thread-4 35766 1688116403614
> end::pool-1-thread-1 35766 1688116403614
> 

[jira] [Commented] (DIRKRB-767) data race when multi KrbClients visit KdcServer

2023-11-29 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-767:


Hi,

I've found some time to take a look. I don't think there is any data race here, 
as we are only ever storing server side information. I've rewritten it a bit to 
use a ConcurrentHashMap and only to store the data in the first place if we 
have a pkinitIdentity

Colm.

> data race when multi KrbClients visit KdcServer
> ---
>
> Key: DIRKRB-767
> URL: https://issues.apache.org/jira/browse/DIRKRB-767
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: lujie
>Priority: Critical
>
> when KDCServer started, it will run a thread to check if has a client request 
> in
> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run() method.
> *server test code:* 
> {code:java}
> // server test code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.server.SimpleKdcServer;
> public class TestServer2 {
> public static void main(String[] args) throws KrbException {
> SimpleKdcServer simpleKdcServer = new SimpleKdcServer();
> simpleKdcServer.setKdcHost("0.0.0.0");
> simpleKdcServer.setKdcRealm("service.ws.apache.org");
> simpleKdcServer.setKdcTcpPort(12345);
> simpleKdcServer.setAllowUdp(true);
> simpleKdcServer.setKdcUdpPort(12346);
> simpleKdcServer.init();
> // Create principals
> String alice = "al...@service.ws.apache.org";
> String bob = "bob/service.ws.apache@service.ws.apache.org";
> //simpleKdcServer.set
> simpleKdcServer.createPrincipal(alice, "alice");
> simpleKdcServer.createPrincipal(bob,"bob");
> simpleKdcServer.start();
> }
> } {code}
> *client test Code*
> {code:java}
> // client test Code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.client.KrbClient;
> import org.apache.kerby.kerberos.kerb.client.KrbPkinitClient;
> import org.apache.kerby.kerberos.kerb.type.ticket.SgtTicket;
> import org.apache.kerby.kerberos.kerb.type.ticket.TgtTicket;
> public class TestClient3 {
> public static void main(String[] args) {
> for (int i = 0; i < 10; i++) {
> System.out.println(i);
> new Thread(()->{
> try {
> KrbClient client = new KrbClient();
> client.setKdcHost("0.0.0.0");
> client.setKdcTcpPort(12345);
> client.setKdcUdpPort(12346);
> client.setKdcRealm("TEST2.COM");
> client.init();
> TgtTicket tgt;
> SgtTicket tkt;
> tgt = client.requestTgt("al...@service.ws.apache.org", 
> "alice");
> tkt = client.requestSgt(tgt, 
> "bob/service.ws.apache@service.ws.apache.org");
> } catch (KrbException e) {
> }
> }).start();
> }
> }
> }
>  {code}
> *method : 
> org.apache.kerby.kerberos.kerb.server.preauth.pkinit.PkinitPreauth.initWith(KdcContext
>  kdcContext)*
> *In order to make the results more visible, I inserted several lines of code, 
> such as {{System.out.println()}} and {{{}Thread.sleep(new 
> Random().nextInt(10)){}}}. Please let me know if there are any syntax errors.*
> {code:java}
> public void initWith(KdcContext kdcContext) {
> super.initWith(kdcContext);
> PkinitKdcContext tmp = new PkinitKdcContext();
> tmp.realm = kdcContext.getKdcRealm();
> String pkinitIdentity = kdcContext.getConfig().getPkinitIdentity();
> tmp.identityOpts.setIdentity(pkinitIdentity);
> System.out.println("start::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> try {
> Thread.sleep(new Random().nextInt(10));
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> pkinitContexts.put(kdcContext.getKdcRealm(), tmp);
> System.out.println("end::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> }{code}
>  After run the server and client, we will get the part of result:
> {panel}
> start::pool-1-thread-6 35766 1688116403609
> start::pool-1-thread-4 35766 1688116403609
> end::pool-1-thread-6 35766 1688116403610
> start::pool-1-thread-1 35766 1688116403609
> start::pool-1-thread-9 35766 1688116403609
> start::pool-1-thread-2 35766 1688116403609
> start::pool-1-thread-7 35766 1688116403609
> start::pool-1-thread-5 35766 1688116403609
> start::pool-1-thread-3 35766 1688116403609
> 

[jira] [Updated] (DIRKRB-767) data race when multi KrbClients visit KdcServer

2023-11-29 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-767:
---
Fix Version/s: 2.1.0

> data race when multi KrbClients visit KdcServer
> ---
>
> Key: DIRKRB-767
> URL: https://issues.apache.org/jira/browse/DIRKRB-767
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: lujie
>Priority: Minor
> Fix For: 2.1.0
>
>
> when KDCServer started, it will run a thread to check if has a client request 
> in
> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run() method.
> *server test code:* 
> {code:java}
> // server test code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.server.SimpleKdcServer;
> public class TestServer2 {
> public static void main(String[] args) throws KrbException {
> SimpleKdcServer simpleKdcServer = new SimpleKdcServer();
> simpleKdcServer.setKdcHost("0.0.0.0");
> simpleKdcServer.setKdcRealm("service.ws.apache.org");
> simpleKdcServer.setKdcTcpPort(12345);
> simpleKdcServer.setAllowUdp(true);
> simpleKdcServer.setKdcUdpPort(12346);
> simpleKdcServer.init();
> // Create principals
> String alice = "al...@service.ws.apache.org";
> String bob = "bob/service.ws.apache@service.ws.apache.org";
> //simpleKdcServer.set
> simpleKdcServer.createPrincipal(alice, "alice");
> simpleKdcServer.createPrincipal(bob,"bob");
> simpleKdcServer.start();
> }
> } {code}
> *client test Code*
> {code:java}
> // client test Code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.client.KrbClient;
> import org.apache.kerby.kerberos.kerb.client.KrbPkinitClient;
> import org.apache.kerby.kerberos.kerb.type.ticket.SgtTicket;
> import org.apache.kerby.kerberos.kerb.type.ticket.TgtTicket;
> public class TestClient3 {
> public static void main(String[] args) {
> for (int i = 0; i < 10; i++) {
> System.out.println(i);
> new Thread(()->{
> try {
> KrbClient client = new KrbClient();
> client.setKdcHost("0.0.0.0");
> client.setKdcTcpPort(12345);
> client.setKdcUdpPort(12346);
> client.setKdcRealm("TEST2.COM");
> client.init();
> TgtTicket tgt;
> SgtTicket tkt;
> tgt = client.requestTgt("al...@service.ws.apache.org", 
> "alice");
> tkt = client.requestSgt(tgt, 
> "bob/service.ws.apache@service.ws.apache.org");
> } catch (KrbException e) {
> }
> }).start();
> }
> }
> }
>  {code}
> *method : 
> org.apache.kerby.kerberos.kerb.server.preauth.pkinit.PkinitPreauth.initWith(KdcContext
>  kdcContext)*
> *In order to make the results more visible, I inserted several lines of code, 
> such as {{System.out.println()}} and {{{}Thread.sleep(new 
> Random().nextInt(10)){}}}. Please let me know if there are any syntax errors.*
> {code:java}
> public void initWith(KdcContext kdcContext) {
> super.initWith(kdcContext);
> PkinitKdcContext tmp = new PkinitKdcContext();
> tmp.realm = kdcContext.getKdcRealm();
> String pkinitIdentity = kdcContext.getConfig().getPkinitIdentity();
> tmp.identityOpts.setIdentity(pkinitIdentity);
> System.out.println("start::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> try {
> Thread.sleep(new Random().nextInt(10));
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> pkinitContexts.put(kdcContext.getKdcRealm(), tmp);
> System.out.println("end::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> }{code}
>  After run the server and client, we will get the part of result:
> {panel}
> start::pool-1-thread-6 35766 1688116403609
> start::pool-1-thread-4 35766 1688116403609
> end::pool-1-thread-6 35766 1688116403610
> start::pool-1-thread-1 35766 1688116403609
> start::pool-1-thread-9 35766 1688116403609
> start::pool-1-thread-2 35766 1688116403609
> start::pool-1-thread-7 35766 1688116403609
> start::pool-1-thread-5 35766 1688116403609
> start::pool-1-thread-3 35766 1688116403609
> start::pool-1-thread-10 35766 1688116403609
> start::pool-1-thread-8 35766 1688116403609
> end::pool-1-thread-5 35766 1688116403613
> end::pool-1-thread-2 35766 1688116403613
> end::pool-1-thread-4 35766 1688116403614
> end::pool-1-thread-1 

[jira] [Commented] (DIRKRB-772) Why hasn't it been implemented etype_info2

2023-11-28 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-772:


Hi,

If it hasn't been implemented, it's because no-one has needed it to be 
implemented :) We're an open source project and gratefully accept 
contributions, you can submit a pull request here 
[https://github.com/apache/directory-kerby/pulls]

Colm.

> Why hasn't it been implemented etype_info2 
> ---
>
> Key: DIRKRB-772
> URL: https://issues.apache.org/jira/browse/DIRKRB-772
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: scott.zhai
>Priority: Trivial
>
> {code}
> /*
>  * If the client performed optimistic pre-authentication for a 
> multi-round-trip
>  * mechanism, it may need key information to complete the exchange, so send it
>  * a PA-ETYPE-INFO2 element in addition to the pa-data from the module.
>  */
> static krb5_error_code
> maybe_add_etype_info2(struct padata_state *state, krb5_error_code code)
> {
> krb5_context context = state->context;
> krb5_kdcpreauth_rock rock = state->rock;
> krb5_pa_data **list = state->pa_e_data;
> size_t count;
> /* Only add key information when requesting another preauth round trip. */
> if (code != KRB5KDC_ERR_MORE_PREAUTH_DATA_REQUIRED)
> return 0;
> /* Don't try to add key information when there is no key. */
> if (rock->client_key == NULL)
> return 0;
> /* If the client sent a cookie, it has already seen a KDC response with 
> key
>  * information. */
> if (krb5int_find_pa_data(context, state->request->padata,
>  KRB5_PADATA_FX_COOKIE) != NULL)
> return 0;
> /* Reallocate state->pa_e_data to make room for the etype-info2 element. 
> */
> for (count = 0; list != NULL && list[count] != NULL; count++);
> list = realloc(list, (count + 2) * sizeof(*list));
> if (list == NULL)
> return ENOMEM;
> list[count] = list[count + 1] = NULL;
> state->pa_e_data = list;
> /* Generate an etype-info2 element in the new slot. */
> return make_etype_info(context, KRB5_PADATA_ETYPE_INFO2,
>rock->client->princ, rock->client_key,
>rock->client_keyblock->enctype, [count]);
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-773) jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);

2023-11-28 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-773:


Can you submit the description again, I just see a blank box?

 

Colm.

> jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);
> ---
>
> Key: DIRKRB-773
> URL: https://issues.apache.org/jira/browse/DIRKRB-773
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: scott.zhai
>Priority: Major
>
> {code}
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-771) Why hasn't it been implemented ENCPADATA_REQ_ENC_PA_REP

2023-11-28 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-771:


Hi,

If it hasn't been implemented, it's because no-one has needed it to be 
implemented :) We're an open source project and gratefully accept 
contributions, you can submit a pull request here 
[https://github.com/apache/directory-kerby/pulls]

Colm.

> Why hasn't it been implemented ENCPADATA_REQ_ENC_PA_REP 
> 
>
> Key: DIRKRB-771
> URL: https://issues.apache.org/jira/browse/DIRKRB-771
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: scott.zhai
>Priority: Trivial
>
> {code}
> krb5_error_code
> kdc_handle_protected_negotiation(krb5_context context,
>  krb5_data *req_pkt, krb5_kdc_req *request,
>  const krb5_keyblock *reply_key,
>  krb5_pa_data ***out_enc_padata)
> {
> krb5_error_code retval = 0;
> krb5_checksum checksum;
> krb5_data *out = NULL;
> krb5_pa_data pa, *pa_in;
> pa_in = krb5int_find_pa_data(context, request->padata,
>  KRB5_ENCPADATA_REQ_ENC_PA_REP);
> if (pa_in == NULL)
> return 0;
> pa.magic = KV5M_PA_DATA;
> pa.pa_type = KRB5_ENCPADATA_REQ_ENC_PA_REP;
> memset(, 0, sizeof(checksum));
> retval = krb5_c_make_checksum(context,0, reply_key,
>   KRB5_KEYUSAGE_AS_REQ, req_pkt, );
> if (retval != 0)
> goto cleanup;
> retval = encode_krb5_checksum(, );
> if (retval != 0)
> goto cleanup;
> pa.contents = (krb5_octet *) out->data;
> pa.length = out->length;
> retval = add_pa_data_element(context, , out_enc_padata, FALSE);
> if (retval)
> goto cleanup;
> out->data = NULL;
> pa.magic = KV5M_PA_DATA;
> pa.pa_type = KRB5_PADATA_FX_FAST;
> pa.length = 0;
> pa.contents = NULL;
> retval = add_pa_data_element(context, , out_enc_padata, FALSE);
> cleanup:
> if (checksum.contents)
> krb5_free_checksum_contents(context, );
> if (out != NULL)
> krb5_free_data(context, out);
> return retval;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-763) KVNO is not updated and always set to 1 when using LocalKadmin.changePassword(String, String) method

2023-11-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-763.

Resolution: Fixed

> KVNO is not updated and always set to 1 when using 
> LocalKadmin.changePassword(String, String) method
> 
>
> Key: DIRKRB-763
> URL: https://issues.apache.org/jira/browse/DIRKRB-763
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Dmitry Bedrin
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I'm trying to update password for my server Kerberos account without service 
> disruption.
> In order to achieve it I need to create an EncryptionKey with incremented 
> KVNO.
> However existing `LocalKadminImpl.changePassword` implementation always sets 
> it to 1



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] (DIRKRB-763) KVNO is not updated and always set to 1 when using LocalKadmin.changePassword(String, String) method

2023-11-08 Thread Colm O hEigeartaigh (Jira)


[ https://issues.apache.org/jira/browse/DIRKRB-763 ]


Colm O hEigeartaigh deleted comment on DIRKRB-763:


was (Author: coheigea):
Can you consider contributing a patch for this to 
[https://github.com/apache/directory-kerby] ?

> KVNO is not updated and always set to 1 when using 
> LocalKadmin.changePassword(String, String) method
> 
>
> Key: DIRKRB-763
> URL: https://issues.apache.org/jira/browse/DIRKRB-763
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Dmitry Bedrin
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I'm trying to update password for my server Kerberos account without service 
> disruption.
> In order to achieve it I need to create an EncryptionKey with incremented 
> KVNO.
> However existing `LocalKadminImpl.changePassword` implementation always sets 
> it to 1



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-763) KVNO is not updated and always set to 1 when using LocalKadmin.changePassword(String, String) method

2023-11-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-763:
---
Fix Version/s: 2.1.0

> KVNO is not updated and always set to 1 when using 
> LocalKadmin.changePassword(String, String) method
> 
>
> Key: DIRKRB-763
> URL: https://issues.apache.org/jira/browse/DIRKRB-763
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Dmitry Bedrin
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.1.0
>
>
> I'm trying to update password for my server Kerberos account without service 
> disruption.
> In order to achieve it I need to create an EncryptionKey with incremented 
> KVNO.
> However existing `LocalKadminImpl.changePassword` implementation always sets 
> it to 1



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Assigned] (DIRKRB-763) KVNO is not updated and always set to 1 when using LocalKadmin.changePassword(String, String) method

2023-11-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-763:
--

Assignee: Colm O hEigeartaigh

> KVNO is not updated and always set to 1 when using 
> LocalKadmin.changePassword(String, String) method
> 
>
> Key: DIRKRB-763
> URL: https://issues.apache.org/jira/browse/DIRKRB-763
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Dmitry Bedrin
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> I'm trying to update password for my server Kerberos account without service 
> disruption.
> In order to achieve it I need to create an EncryptionKey with incremented 
> KVNO.
> However existing `LocalKadminImpl.changePassword` implementation always sets 
> it to 1



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-738) Package name conflicts between sub-projects create problems with Java modules

2023-11-06 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-738:
---
Fix Version/s: (was: 2.1.0)

> Package name conflicts between sub-projects create problems with Java modules
> -
>
> Key: DIRKRB-738
> URL: https://issues.apache.org/jira/browse/DIRKRB-738
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Richard Feezel
>Priority: Major
>  Labels: patch
> Attachments: kerby-package-conflicts.patch
>
>
> Eclipse now flags as errors attempts to access classes contained in a package 
> that is declared in more than one Jar (module). The current Kerby code base 
> has problems with the "org.apache.kerby.kerberos.kerb" and "org.apache.kerby" 
> packages in this regard. The affected projects are kerb-common, kerby-util, 
> kerb-core, kerb-util, and mavibot-backend. My approach to addressing this is 
> to create project-specific packages and moving the classes from these problem 
> package names to the new, project-specific ones. These changes, of course, 
> impact all uses of these moved classes resulting in many changes throughout 
> the Kerby system.
> Also included in the attached patch is a modification to the call to the 
> sun.security.krb5.Credentials constructor in has.client.HasLoginModule() to 
> add values for the new parameters.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-770) Migrate to Apache DS 2.0.0.AM27 and LDAP API 2.1.5

2023-10-26 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-770:
---
Fix Version/s: 2.1.0

> Migrate to Apache DS 2.0.0.AM27 and LDAP API 2.1.5
> --
>
> Key: DIRKRB-770
> URL: https://issues.apache.org/jira/browse/DIRKRB-770
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.1.0
>
>
> Migrate to Apache DS 2.0.0.AM27 and LDAP API 2.1.5



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Created] (DIRKRB-770) Migrate to Apache DS 2.0.0.AM27 and LDAP API 2.1.5

2023-10-26 Thread Colm O hEigeartaigh (Jira)
Colm O hEigeartaigh created DIRKRB-770:
--

 Summary: Migrate to Apache DS 2.0.0.AM27 and LDAP API 2.1.5
 Key: DIRKRB-770
 URL: https://issues.apache.org/jira/browse/DIRKRB-770
 Project: Directory Kerberos
  Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh


Migrate to Apache DS 2.0.0.AM27 and LDAP API 2.1.5



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRSERVER-2385) ApacheDS cannot run on Java21

2023-10-24 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2385.

Resolution: Fixed

Please try the recent 2.0.0.AM27 release, we already fixed this issue.

> ApacheDS cannot run on Java21
> -
>
> Key: DIRSERVER-2385
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2385
> Project: Directory ApacheDS
>  Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: Tamas Cservenak
>Priority: Major
>
> ApacheDS fails to start on Java 21, thrown exception is:
> {noformat}
> java.lang.NoSuchMethodError: 'void 
> sun.security.x509.X509CertInfo.set(java.lang.String, java.lang.Object)'
>   at 
> org.apache.directory.server.core.security.CertificateUtil.setInfo(CertificateUtil.java:96)
>   at 
> org.apache.directory.server.core.security.CertificateUtil.generateSelfSignedCertificate(CertificateUtil.java:194)
>   at 
> org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:337)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
>   at 
> org.apache.directory.server.core.integ.CreateLdapServerRule$2.evaluate(CreateLdapServerRule.java:112)
>   at 
> org.apache.directory.server.core.integ.CreateDsRule$2.evaluate(CreateDsRule.java:124)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRAPI-394) Add support for control 1.3.6.1.4.1.30221.2.5.44 (Naming Entries With entryUUID)

2023-08-27 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRAPI-394:
---
Fix Version/s: (was: 2.1.4)

> Add support for control 1.3.6.1.4.1.30221.2.5.44 (Naming Entries With 
> entryUUID)
> 
>
> Key: DIRAPI-394
> URL: https://issues.apache.org/jira/browse/DIRAPI-394
> Project: Directory Client API
>  Issue Type: Task
>Affects Versions: 2.1.3
>Reporter: Emmanuel Lécharny
>Priority: Major
>
> It would be a good addition to support control "Naming Entries With entryUUID"
>  
> See [Neil Wilson 
> blog|https://nawilson.com/2019/04/29/naming-entries-with-entryuuid-in-the-ping-identity-directory-server/]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-767) data race when multi KrbClients visit KdcServer

2023-08-17 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-767:


Hi [~xiaoheipangzi] ,

If you could suggest a fix would you be willing to submit a pull request to fix 
it? [https://github.com/apache/directory-kerby]

Otherwise I'll have a look in a few weeks.

Colm.

> data race when multi KrbClients visit KdcServer
> ---
>
> Key: DIRKRB-767
> URL: https://issues.apache.org/jira/browse/DIRKRB-767
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: lujie
>Priority: Critical
>
> when KDCServer started, it will run a thread to check if has a client request 
> in
> org.apache.kerby.kerberos.kerb.transport.KdcNetwork.run() method.
> *server test code:* 
> {code:java}
> // server test code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.server.SimpleKdcServer;
> public class TestServer2 {
> public static void main(String[] args) throws KrbException {
> SimpleKdcServer simpleKdcServer = new SimpleKdcServer();
> simpleKdcServer.setKdcHost("0.0.0.0");
> simpleKdcServer.setKdcRealm("service.ws.apache.org");
> simpleKdcServer.setKdcTcpPort(12345);
> simpleKdcServer.setAllowUdp(true);
> simpleKdcServer.setKdcUdpPort(12346);
> simpleKdcServer.init();
> // Create principals
> String alice = "al...@service.ws.apache.org";
> String bob = "bob/service.ws.apache@service.ws.apache.org";
> //simpleKdcServer.set
> simpleKdcServer.createPrincipal(alice, "alice");
> simpleKdcServer.createPrincipal(bob,"bob");
> simpleKdcServer.start();
> }
> } {code}
> *client test Code*
> {code:java}
> // client test Code
> import org.apache.kerby.kerberos.kerb.KrbException;
> import org.apache.kerby.kerberos.kerb.client.KrbClient;
> import org.apache.kerby.kerberos.kerb.client.KrbPkinitClient;
> import org.apache.kerby.kerberos.kerb.type.ticket.SgtTicket;
> import org.apache.kerby.kerberos.kerb.type.ticket.TgtTicket;
> public class TestClient3 {
> public static void main(String[] args) {
> for (int i = 0; i < 10; i++) {
> System.out.println(i);
> new Thread(()->{
> try {
> KrbClient client = new KrbClient();
> client.setKdcHost("0.0.0.0");
> client.setKdcTcpPort(12345);
> client.setKdcUdpPort(12346);
> client.setKdcRealm("TEST2.COM");
> client.init();
> TgtTicket tgt;
> SgtTicket tkt;
> tgt = client.requestTgt("al...@service.ws.apache.org", 
> "alice");
> tkt = client.requestSgt(tgt, 
> "bob/service.ws.apache@service.ws.apache.org");
> } catch (KrbException e) {
> }
> }).start();
> }
> }
> }
>  {code}
> *method : 
> org.apache.kerby.kerberos.kerb.server.preauth.pkinit.PkinitPreauth.initWith(KdcContext
>  kdcContext)*
> *In order to make the results more visible, I inserted several lines of code, 
> such as {{System.out.println()}} and {{{}Thread.sleep(new 
> Random().nextInt(10)){}}}. Please let me know if there are any syntax errors.*
> {code:java}
> public void initWith(KdcContext kdcContext) {
> super.initWith(kdcContext);
> PkinitKdcContext tmp = new PkinitKdcContext();
> tmp.realm = kdcContext.getKdcRealm();
> String pkinitIdentity = kdcContext.getConfig().getPkinitIdentity();
> tmp.identityOpts.setIdentity(pkinitIdentity);
> System.out.println("start::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> try {
> Thread.sleep(new Random().nextInt(10));
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> pkinitContexts.put(kdcContext.getKdcRealm(), tmp);
> System.out.println("end::" +Thread.currentThread().getName()+ " 
> "+System.identityHashCode(pkinitContexts)+" "+ System.currentTimeMillis());
> }{code}
>  After run the server and client, we will get the part of result:
> {panel}
> start::pool-1-thread-6 35766 1688116403609
> start::pool-1-thread-4 35766 1688116403609
> end::pool-1-thread-6 35766 1688116403610
> start::pool-1-thread-1 35766 1688116403609
> start::pool-1-thread-9 35766 1688116403609
> start::pool-1-thread-2 35766 1688116403609
> start::pool-1-thread-7 35766 1688116403609
> start::pool-1-thread-5 35766 1688116403609
> start::pool-1-thread-3 35766 1688116403609
> start::pool-1-thread-10 35766 1688116403609
> start::pool-1-thread-8 

[jira] [Resolved] (DIRKRB-766) Publish a kerby-bom POM

2023-04-07 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-766.

Resolution: Fixed

> Publish a kerby-bom POM
> ---
>
> Key: DIRKRB-766
> URL: https://issues.apache.org/jira/browse/DIRKRB-766
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.1.0, 2.0.4
>
>
> It would help simplify parent POMs if Kerby would publish a BOM POM 
> "kerby-bom".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-766) Publish a kerby-bom POM

2023-04-06 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-766:
---
Fix Version/s: 2.0.4

> Publish a kerby-bom POM
> ---
>
> Key: DIRKRB-766
> URL: https://issues.apache.org/jira/browse/DIRKRB-766
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.1.0, 2.0.4
>
>
> It would help simplify parent POMs if Kerby would publish a BOM POM 
> "kerby-bom".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-766) Publish a kerby-bom POM

2023-04-06 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-766:
---
Fix Version/s: 2.1.0

> Publish a kerby-bom POM
> ---
>
> Key: DIRKRB-766
> URL: https://issues.apache.org/jira/browse/DIRKRB-766
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.1.0
>
>
> It would help simplify parent POMs if Kerby would publish a BOM POM 
> "kerby-bom".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Assigned] (DIRKRB-766) Publish a kerby-bom POM

2023-04-06 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-766:
--

Assignee: Colm O hEigeartaigh

> Publish a kerby-bom POM
> ---
>
> Key: DIRKRB-766
> URL: https://issues.apache.org/jira/browse/DIRKRB-766
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> It would help simplify parent POMs if Kerby would publish a BOM POM 
> "kerby-bom".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-729) Upgrade LDAP API

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-729:
---
Fix Version/s: 1.1.2

> Upgrade LDAP API
> 
>
> Key: DIRKRB-729
> URL: https://issues.apache.org/jira/browse/DIRKRB-729
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0, 1.1.2
>
> Attachments: DIRKRB-729.patch
>
>
> We should upgrade the LDAP API to match the most recent release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Reopened] (DIRKRB-729) Upgrade LDAP API

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reopened DIRKRB-729:


> Upgrade LDAP API
> 
>
> Key: DIRKRB-729
> URL: https://issues.apache.org/jira/browse/DIRKRB-729
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: DIRKRB-729.patch
>
>
> We should upgrade the LDAP API to match the most recent release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-729) Upgrade LDAP API

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-729.

Resolution: Fixed

> Upgrade LDAP API
> 
>
> Key: DIRKRB-729
> URL: https://issues.apache.org/jira/browse/DIRKRB-729
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.1.2, 2.0.0
>
> Attachments: DIRKRB-729.patch
>
>
> We should upgrade the LDAP API to match the most recent release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Reopened] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reopened DIRKRB-747:


> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-747.

Resolution: Fixed

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.1.2, 2.0.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-747:
---
Fix Version/s: 1.1.2

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.1.2, 2.0.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-737) Update Nimbus Jose

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-737:
---
Fix Version/s: 1.1.2

> Update Nimbus Jose
> --
>
> Key: DIRKRB-737
> URL: https://issues.apache.org/jira/browse/DIRKRB-737
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.1.2, 2.0.1
>
>
> We need to update Nimbus Jose to pick up a fix for 
> https://nvd.nist.gov/vuln/detail/CVE-2019-17195



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Reopened] (DIRKRB-737) Update Nimbus Jose

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reopened DIRKRB-737:


> Update Nimbus Jose
> --
>
> Key: DIRKRB-737
> URL: https://issues.apache.org/jira/browse/DIRKRB-737
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.1
>
>
> We need to update Nimbus Jose to pick up a fix for 
> https://nvd.nist.gov/vuln/detail/CVE-2019-17195



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-737) Update Nimbus Jose

2023-03-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-737.

Resolution: Fixed

> Update Nimbus Jose
> --
>
> Key: DIRKRB-737
> URL: https://issues.apache.org/jira/browse/DIRKRB-737
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 1.1.2, 2.0.1
>
>
> We need to update Nimbus Jose to pick up a fix for 
> https://nvd.nist.gov/vuln/detail/CVE-2019-17195



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-765) Remove has-project

2023-02-26 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-765.

Resolution: Fixed

> Remove has-project
> --
>
> Key: DIRKRB-765
> URL: https://issues.apache.org/jira/browse/DIRKRB-765
> Project: Directory Kerberos
>  Issue Type: Task
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This task is to remove has-project from 2.1.0 as it's not maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Created] (DIRKRB-765) Remove has-project

2023-02-22 Thread Colm O hEigeartaigh (Jira)
Colm O hEigeartaigh created DIRKRB-765:
--

 Summary: Remove has-project
 Key: DIRKRB-765
 URL: https://issues.apache.org/jira/browse/DIRKRB-765
 Project: Directory Kerberos
  Issue Type: Task
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 2.1.0


This task is to remove has-project from 2.1.0 as it's not maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Closed] (DIRKRB-760) The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a vulnerability

2023-02-19 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-760.
--

> The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a 
> vulnerability
> --
>
> Key: DIRKRB-760
> URL: https://issues.apache.org/jira/browse/DIRKRB-760
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Albert Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>
> *org.apache.kerby:kerb-common:jar:2.0.2* has a dependency library 
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final*.
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final* has a vulnerability CVE-2022-0084 
> which is fixed in *3.8.8.Final*.
> Can we upgrade the dependency to *3.8.8.Final*? Or, can we confirm that 
> *org.apache.kerby:kerb-common:jar:2.0.2* does not use the impact method of 
> *org.jboss.xnio:xnio-api:jar:3.8.4*?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Closed] (DIRKRB-761) The ticket lifetime obtained by the Kerberos client may be larger than the maximum set on the KDC

2023-02-19 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-761.
--

> The ticket lifetime obtained by the Kerberos client may be larger than the 
> maximum set on the KDC
> -
>
> Key: DIRKRB-761
> URL: https://issues.apache.org/jira/browse/DIRKRB-761
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2
>Reporter: Jichao Wang
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The ticket lifetime obtained by the Kerberos client may be greater than the 
> maximum lifetime configured on the KDC (maximum_ticket_lifetime)
> The contents of kdc.conf are as follows:
> {code:java}
> [kdcdefaults]
>   kdc_host = krb-wjc-kerberos-0
>   kdc_udp_port = 88
>   kdc_tcp_port = 88
>   kdc_realm = HADOOP.COM
>   encryption_types = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
>   preauth_required = false
>   maximum_renewable_lifetime = 0
>   maximum_ticket_lifetime = 86400
>   minimum_ticket_lifetime = 0 {code}
> Based on the above configuration, the maximum ticket lifetime obtained by the 
> Kerberos client should be 1 day. However, when I use the following krb5.conf 
> and methods to obtain the ticket, the lifetime of the ticket is 3 days, which 
> is larger than the maximum set on KDC of 1 day.
> The contents of krb5.conf are as follows:
> {code:java}
> [libdefaults]
>  dns_lookup_realm = false
>  dns_lookup_kdc = false
>  ticket_lifetime = 72h
>  renew_lifetime = 0
>  forwardable = false
>  renewable = false
>  rdns = false
>  default_realm = HADOOP.COM
>  default_ccache_name = /tmp/krb5cc_%{uid}
>  udp_preference_limit = 1
> [realms]
>  HADOOP.COM = {
>   kdc = krb-wjc-kerberos-0
>  } {code}
> First install the Kerberos client on the Centos7 operating system by running 
> the following command:
> {code:java}
> yum install -y krb5-devel krb5-workstation {code}
> Then use kinit to get the ticket from KDC and use the klist command to view 
> the ticket:
> {code:java}
> [root@localhost wjc]# kinit had...@hadoop.com
> Password for had...@hadoop.com:
> [root@localhost wjc]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: had...@hadoop.com
> Valid starting       Expires              Service principal
> 12/03/2022 16:44:10  12/06/2022 16:44:10  krbtgt/hadoop@hadoop.com
>         renew until 12/03/2022 16:44:10 {code}
> We can see that the lifetime of the Kerberos ticket is 3 days, which is 
> larger than the 1 day set in kdc.conf. This may cause security risks.
> So I think this is a bug.
> Here's how I fix it:
> Add a maximum life cycle to the condition of the if statement at 
> _org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java:173_ to 
> ensure that the ticket lifetime obtained by the client is not greater than 
> the maximum lifetime configured on the KDC.
> {code:java}
> Index: 
> kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===
> diff --git 
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
>  
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
> --- 
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
>     (revision 8cdcd544d14af1f876e3bbb16c959f30de79577d)
> +++ 
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
>     (revision 242ef1024a66169516e636030c1e720a94f35ef1)
> @@ -169,8 +169,9 @@
>          }
>  
>          KerberosTime krbEndTime = request.getReqBody().getTill();
> -        if (krbEndTime == null || krbEndTime.getTime() == 0) {
> -            krbEndTime = 
> krbStartTime.extend(config.getMaximumTicketLifetime() * 1000);
> +        KerberosTime maxEndTime = 
> krbStartTime.extend(config.getMaximumTicketLifetime() * 1000);
> +        if (krbEndTime == null || krbEndTime.getTime() == 0 || 
> krbEndTime.greaterThan(maxEndTime)) {
> +            krbEndTime = maxEndTime;
>          } else if (krbStartTime.greaterThan(krbEndTime)) {
>              throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>          }{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Closed] (DIRKRB-762) The AS request appears with an NPE when preauth_required is set to false

2023-02-19 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-762.
--

> The AS request appears with an NPE when preauth_required is set to false
> 
>
> Key: DIRKRB-762
> URL: https://issues.apache.org/jira/browse/DIRKRB-762
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2
>Reporter: Jichao Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
> Attachments: kdc-npe.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If change the value of preauth_required in the kdc.conf file to false, then 
> using the following code to access the KDC causes an NPE error.
>  * Test.java
> {code:java}
> // Test.java Run on JDK8 or JDK11
> public class Test {
>     public static void main(String[] args) throws Exception {
>  System.setProperty("java.security.krb5.realm", "HADOOP.COM");
>  System.setProperty("java.security.krb5.kdc", "wslhost");
>          LoginContext lc = new LoginContext("SampleClient",
>                 new Subject(),
>                 null,
>                 new CustomConfiguration("had...@hadoop.com", 
> "/root/wjc/hadoop.keytab"));
>         lc.login();
>         System.out.println(lc.getSubject().toString());
>     }
> } {code}
>  * 
> CustomConfiguration.java
> {code:java}
> import javax.security.auth.login.AppConfigurationEntry;
> import java.util.HashMap;
> import java.util.Map;
> class CustomConfiguration
> extends javax.security.auth.login.Configuration {
> private static final Map BASIC_JAAS_OPTIONS =
> new HashMap();
> private static final Map KEYTAB_KERBEROS_OPTIONS =
> new HashMap();
> private static final AppConfigurationEntry KEYTAB_KERBEROS_LOGIN =
> new 
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
> KEYTAB_KERBEROS_OPTIONS);
> private static final AppConfigurationEntry[] KEYTAB_KERBEROS_CONF =
> new AppConfigurationEntry[]{KEYTAB_KERBEROS_LOGIN};
> static {
> KEYTAB_KERBEROS_OPTIONS.put("doNotPrompt", "true");
> KEYTAB_KERBEROS_OPTIONS.put("useKeyTab", "true");
> KEYTAB_KERBEROS_OPTIONS.put("storeKey", "true");
> KEYTAB_KERBEROS_OPTIONS.put("refreshKrb5Config", "true");
> KEYTAB_KERBEROS_OPTIONS.putAll(BASIC_JAAS_OPTIONS);
> }
> private String keytabPrincipal;
> private String keytabFile;
> public CustomConfiguration(String keytabPrincipal, String keytabFile) {
> this.keytabPrincipal = keytabPrincipal;
> this.keytabFile = keytabFile;
> }
> private CustomConfiguration() {
> }
> public String getKeytabFile() {
> return keytabFile;
> }
> public String getKeytabPrincipal() {
> return keytabPrincipal;
> }
> @Override
> public AppConfigurationEntry[] getAppConfigurationEntry(String appName) {
> KEYTAB_KERBEROS_OPTIONS.put("keyTab", keytabFile);
> KEYTAB_KERBEROS_OPTIONS.put("principal", keytabPrincipal);
> return KEYTAB_KERBEROS_CONF;
> }
> } {code}
> Kerberos client error information is as follows:
> {code:java}
> Exception in thread "main" javax.security.auth.login.LoginException: null 
> (5001)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:781)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:592)
>     at 
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
>     at 
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
>     at 
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at 
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
>     at 
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
>     at org.example.Main.main(Main.java:14)
> Caused by: KrbException: null (5001)
>     at java.security.jgss/sun.security.krb5.KrbAsRep.(KrbAsRep.java:76)
>     at 
> java.security.jgss/sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:326)
>     at 
> java.security.jgss/sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:371)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:753)
>     ... 8 more
> Caused by: KrbException: Identifier doesn't match expected value (906)
>     at 
> 

[jira] [Closed] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-02-19 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-747.
--

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Closed] (DIRKRB-764) ClassCastException during KerbConf creation

2023-02-19 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-764.
--

> ClassCastException during KerbConf creation
> ---
>
> Key: DIRKRB-764
> URL: https://issues.apache.org/jira/browse/DIRKRB-764
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Serge Shikov
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Groovy code with kerby 2.0.1:
> {code:java}
> File confFile = new File("/etc/krb5.conf")
> KrbConfig conf = new KrbConfig()
> conf.addKrb5Config(confFile){code}
> Completed with exception at line 3:  
> Caught: java.lang.RuntimeException: Failed to load org.apache.kerby.config
> java.lang.RuntimeException: Failed to load org.apache.kerby.config
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:43)
>     at org.apache.kerby.config.Conf.addResource(Conf.java:79)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf.addKrb5Config(Krb5Conf.java:50)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf$addKrb5Config.call(Unknown 
> Source)
>     at SparkRunner.main(kerby.groovy:134)
>     at com.github.igorsuhorukov.groovy.GroovyMain.main(GroovyMain.java:11)
> Caused by: java.lang.ClassCastException: java.util.IdentityHashMap cannot be 
> cast to java.lang.String
>     at 
> org.apache.kerby.config.MapConfigLoader.loadStringMap(MapConfigLoader.java:45)
>     at 
> org.apache.kerby.config.MapConfigLoader.loadConfig(MapConfigLoader.java:35)
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:41)
>     ... 5 more
> As I can understand, this exception is a result of this lines in krb5.conf:
> includedir /etc/krb5.conf.d/
> includedir /etc/krb5.include.d/
> Just second line also causes the same exception, even when 
> /etc/krb5.include.d is empty directory.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-764) ClassCastException during KerbConf creation

2023-01-25 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-764.

Resolution: Fixed

> ClassCastException during KerbConf creation
> ---
>
> Key: DIRKRB-764
> URL: https://issues.apache.org/jira/browse/DIRKRB-764
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Serge Shikov
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Groovy code with kerby 2.0.1:
> {code:java}
> File confFile = new File("/etc/krb5.conf")
> KrbConfig conf = new KrbConfig()
> conf.addKrb5Config(confFile){code}
> Completed with exception at line 3:  
> Caught: java.lang.RuntimeException: Failed to load org.apache.kerby.config
> java.lang.RuntimeException: Failed to load org.apache.kerby.config
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:43)
>     at org.apache.kerby.config.Conf.addResource(Conf.java:79)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf.addKrb5Config(Krb5Conf.java:50)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf$addKrb5Config.call(Unknown 
> Source)
>     at SparkRunner.main(kerby.groovy:134)
>     at com.github.igorsuhorukov.groovy.GroovyMain.main(GroovyMain.java:11)
> Caused by: java.lang.ClassCastException: java.util.IdentityHashMap cannot be 
> cast to java.lang.String
>     at 
> org.apache.kerby.config.MapConfigLoader.loadStringMap(MapConfigLoader.java:45)
>     at 
> org.apache.kerby.config.MapConfigLoader.loadConfig(MapConfigLoader.java:35)
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:41)
>     ... 5 more
> As I can understand, this exception is a result of this lines in krb5.conf:
> includedir /etc/krb5.conf.d/
> includedir /etc/krb5.include.d/
> Just second line also causes the same exception, even when 
> /etc/krb5.include.d is empty directory.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-764) ClassCastException during KerbConf creation

2023-01-25 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-764:
---
Fix Version/s: 2.0.3

> ClassCastException during KerbConf creation
> ---
>
> Key: DIRKRB-764
> URL: https://issues.apache.org/jira/browse/DIRKRB-764
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Serge Shikov
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>
> Groovy code with kerby 2.0.1:
> {code:java}
> File confFile = new File("/etc/krb5.conf")
> KrbConfig conf = new KrbConfig()
> conf.addKrb5Config(confFile){code}
> Completed with exception at line 3:  
> Caught: java.lang.RuntimeException: Failed to load org.apache.kerby.config
> java.lang.RuntimeException: Failed to load org.apache.kerby.config
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:43)
>     at org.apache.kerby.config.Conf.addResource(Conf.java:79)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf.addKrb5Config(Krb5Conf.java:50)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf$addKrb5Config.call(Unknown 
> Source)
>     at SparkRunner.main(kerby.groovy:134)
>     at com.github.igorsuhorukov.groovy.GroovyMain.main(GroovyMain.java:11)
> Caused by: java.lang.ClassCastException: java.util.IdentityHashMap cannot be 
> cast to java.lang.String
>     at 
> org.apache.kerby.config.MapConfigLoader.loadStringMap(MapConfigLoader.java:45)
>     at 
> org.apache.kerby.config.MapConfigLoader.loadConfig(MapConfigLoader.java:35)
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:41)
>     ... 5 more
> As I can understand, this exception is a result of this lines in krb5.conf:
> includedir /etc/krb5.conf.d/
> includedir /etc/krb5.include.d/
> Just second line also causes the same exception, even when 
> /etc/krb5.include.d is empty directory.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Assigned] (DIRKRB-764) ClassCastException during KerbConf creation

2023-01-25 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-764:
--

Assignee: Colm O hEigeartaigh

> ClassCastException during KerbConf creation
> ---
>
> Key: DIRKRB-764
> URL: https://issues.apache.org/jira/browse/DIRKRB-764
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Serge Shikov
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Groovy code with kerby 2.0.1:
> {code:java}
> File confFile = new File("/etc/krb5.conf")
> KrbConfig conf = new KrbConfig()
> conf.addKrb5Config(confFile){code}
> Completed with exception at line 3:  
> Caught: java.lang.RuntimeException: Failed to load org.apache.kerby.config
> java.lang.RuntimeException: Failed to load org.apache.kerby.config
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:43)
>     at org.apache.kerby.config.Conf.addResource(Conf.java:79)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf.addKrb5Config(Krb5Conf.java:50)
>     at 
> org.apache.kerby.kerberos.kerb.common.Krb5Conf$addKrb5Config.call(Unknown 
> Source)
>     at SparkRunner.main(kerby.groovy:134)
>     at com.github.igorsuhorukov.groovy.GroovyMain.main(GroovyMain.java:11)
> Caused by: java.lang.ClassCastException: java.util.IdentityHashMap cannot be 
> cast to java.lang.String
>     at 
> org.apache.kerby.config.MapConfigLoader.loadStringMap(MapConfigLoader.java:45)
>     at 
> org.apache.kerby.config.MapConfigLoader.loadConfig(MapConfigLoader.java:35)
>     at org.apache.kerby.config.ConfigLoader.load(ConfigLoader.java:41)
>     ... 5 more
> As I can understand, this exception is a result of this lines in krb5.conf:
> includedir /etc/krb5.conf.d/
> includedir /etc/krb5.include.d/
> Just second line also causes the same exception, even when 
> /etc/krb5.include.d is empty directory.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-01-19 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-747.

Resolution: Fixed

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-01-18 Thread Colm O hEigeartaigh (Jira)


[ https://issues.apache.org/jira/browse/DIRKRB-747 ]


Colm O hEigeartaigh deleted comment on DIRKRB-747:


was (Author: coheigea):
Could you submit a pull request to fix this issue, or contribute a test-case 
that shows where the problem is?

 

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-01-18 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-747:
---
Fix Version/s: 2.0.3

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Assigned] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2023-01-18 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-747:
--

Assignee: Colm O hEigeartaigh

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-763) KVNO is not updated and always set to 1 when using LocalKadmin.changePassword(String, String) method

2023-01-04 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-763:


Can you consider contributing a patch for this to 
[https://github.com/apache/directory-kerby] ?

> KVNO is not updated and always set to 1 when using 
> LocalKadmin.changePassword(String, String) method
> 
>
> Key: DIRKRB-763
> URL: https://issues.apache.org/jira/browse/DIRKRB-763
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Dmitry Bedrin
>Priority: Minor
>
> I'm trying to update password for my server Kerberos account without service 
> disruption.
> In order to achieve it I need to create an EncryptionKey with incremented 
> KVNO.
> However existing `LocalKadminImpl.changePassword` implementation always sets 
> it to 1



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-762) The AS request appears with an NPE when preauth_required is set to false

2022-12-20 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-762.

Resolution: Fixed

No worries [~wjc920] , and thanks for your contribution to the project.

> The AS request appears with an NPE when preauth_required is set to false
> 
>
> Key: DIRKRB-762
> URL: https://issues.apache.org/jira/browse/DIRKRB-762
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2
>Reporter: Jichao Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
> Attachments: kdc-npe.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If change the value of preauth_required in the kdc.conf file to false, then 
> using the following code to access the KDC causes an NPE error.
>  * Test.java
> {code:java}
> // Test.java Run on JDK8 or JDK11
> public class Test {
>     public static void main(String[] args) throws Exception {
>  System.setProperty("java.security.krb5.realm", "HADOOP.COM");
>  System.setProperty("java.security.krb5.kdc", "wslhost");
>          LoginContext lc = new LoginContext("SampleClient",
>                 new Subject(),
>                 null,
>                 new CustomConfiguration("had...@hadoop.com", 
> "/root/wjc/hadoop.keytab"));
>         lc.login();
>         System.out.println(lc.getSubject().toString());
>     }
> } {code}
>  * 
> CustomConfiguration.java
> {code:java}
> import javax.security.auth.login.AppConfigurationEntry;
> import java.util.HashMap;
> import java.util.Map;
> class CustomConfiguration
> extends javax.security.auth.login.Configuration {
> private static final Map BASIC_JAAS_OPTIONS =
> new HashMap();
> private static final Map KEYTAB_KERBEROS_OPTIONS =
> new HashMap();
> private static final AppConfigurationEntry KEYTAB_KERBEROS_LOGIN =
> new 
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
> KEYTAB_KERBEROS_OPTIONS);
> private static final AppConfigurationEntry[] KEYTAB_KERBEROS_CONF =
> new AppConfigurationEntry[]{KEYTAB_KERBEROS_LOGIN};
> static {
> KEYTAB_KERBEROS_OPTIONS.put("doNotPrompt", "true");
> KEYTAB_KERBEROS_OPTIONS.put("useKeyTab", "true");
> KEYTAB_KERBEROS_OPTIONS.put("storeKey", "true");
> KEYTAB_KERBEROS_OPTIONS.put("refreshKrb5Config", "true");
> KEYTAB_KERBEROS_OPTIONS.putAll(BASIC_JAAS_OPTIONS);
> }
> private String keytabPrincipal;
> private String keytabFile;
> public CustomConfiguration(String keytabPrincipal, String keytabFile) {
> this.keytabPrincipal = keytabPrincipal;
> this.keytabFile = keytabFile;
> }
> private CustomConfiguration() {
> }
> public String getKeytabFile() {
> return keytabFile;
> }
> public String getKeytabPrincipal() {
> return keytabPrincipal;
> }
> @Override
> public AppConfigurationEntry[] getAppConfigurationEntry(String appName) {
> KEYTAB_KERBEROS_OPTIONS.put("keyTab", keytabFile);
> KEYTAB_KERBEROS_OPTIONS.put("principal", keytabPrincipal);
> return KEYTAB_KERBEROS_CONF;
> }
> } {code}
> Kerberos client error information is as follows:
> {code:java}
> Exception in thread "main" javax.security.auth.login.LoginException: null 
> (5001)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:781)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:592)
>     at 
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
>     at 
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
>     at 
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at 
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
>     at 
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
>     at org.example.Main.main(Main.java:14)
> Caused by: KrbException: null (5001)
>     at java.security.jgss/sun.security.krb5.KrbAsRep.(KrbAsRep.java:76)
>     at 
> java.security.jgss/sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:326)
>     at 
> java.security.jgss/sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:371)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:753)
>     ... 8 more
> Caused by: 

[jira] [Assigned] (DIRKRB-762) The AS request appears with an NPE when preauth_required is set to false

2022-12-20 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-762:
--

Assignee: Colm O hEigeartaigh

> The AS request appears with an NPE when preauth_required is set to false
> 
>
> Key: DIRKRB-762
> URL: https://issues.apache.org/jira/browse/DIRKRB-762
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2
>Reporter: Jichao Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
> Attachments: kdc-npe.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If change the value of preauth_required in the kdc.conf file to false, then 
> using the following code to access the KDC causes an NPE error.
>  * Test.java
> {code:java}
> // Test.java Run on JDK8 or JDK11
> public class Test {
>     public static void main(String[] args) throws Exception {
>  System.setProperty("java.security.krb5.realm", "HADOOP.COM");
>  System.setProperty("java.security.krb5.kdc", "wslhost");
>          LoginContext lc = new LoginContext("SampleClient",
>                 new Subject(),
>                 null,
>                 new CustomConfiguration("had...@hadoop.com", 
> "/root/wjc/hadoop.keytab"));
>         lc.login();
>         System.out.println(lc.getSubject().toString());
>     }
> } {code}
>  * 
> CustomConfiguration.java
> {code:java}
> import javax.security.auth.login.AppConfigurationEntry;
> import java.util.HashMap;
> import java.util.Map;
> class CustomConfiguration
> extends javax.security.auth.login.Configuration {
> private static final Map BASIC_JAAS_OPTIONS =
> new HashMap();
> private static final Map KEYTAB_KERBEROS_OPTIONS =
> new HashMap();
> private static final AppConfigurationEntry KEYTAB_KERBEROS_LOGIN =
> new 
> AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule",
> AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
> KEYTAB_KERBEROS_OPTIONS);
> private static final AppConfigurationEntry[] KEYTAB_KERBEROS_CONF =
> new AppConfigurationEntry[]{KEYTAB_KERBEROS_LOGIN};
> static {
> KEYTAB_KERBEROS_OPTIONS.put("doNotPrompt", "true");
> KEYTAB_KERBEROS_OPTIONS.put("useKeyTab", "true");
> KEYTAB_KERBEROS_OPTIONS.put("storeKey", "true");
> KEYTAB_KERBEROS_OPTIONS.put("refreshKrb5Config", "true");
> KEYTAB_KERBEROS_OPTIONS.putAll(BASIC_JAAS_OPTIONS);
> }
> private String keytabPrincipal;
> private String keytabFile;
> public CustomConfiguration(String keytabPrincipal, String keytabFile) {
> this.keytabPrincipal = keytabPrincipal;
> this.keytabFile = keytabFile;
> }
> private CustomConfiguration() {
> }
> public String getKeytabFile() {
> return keytabFile;
> }
> public String getKeytabPrincipal() {
> return keytabPrincipal;
> }
> @Override
> public AppConfigurationEntry[] getAppConfigurationEntry(String appName) {
> KEYTAB_KERBEROS_OPTIONS.put("keyTab", keytabFile);
> KEYTAB_KERBEROS_OPTIONS.put("principal", keytabPrincipal);
> return KEYTAB_KERBEROS_CONF;
> }
> } {code}
> Kerberos client error information is as follows:
> {code:java}
> Exception in thread "main" javax.security.auth.login.LoginException: null 
> (5001)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:781)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:592)
>     at 
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
>     at 
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
>     at 
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at 
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
>     at 
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
>     at org.example.Main.main(Main.java:14)
> Caused by: KrbException: null (5001)
>     at java.security.jgss/sun.security.krb5.KrbAsRep.(KrbAsRep.java:76)
>     at 
> java.security.jgss/sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:326)
>     at 
> java.security.jgss/sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:371)
>     at 
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:753)
>     ... 8 more
> Caused by: KrbException: Identifier doesn't match expected value 

[jira] [Resolved] (DIRKRB-761) The ticket lifetime obtained by the Kerberos client may be larger than the maximum set on the KDC

2022-12-18 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-761.

Resolution: Fixed

Thanks for the PR.

> The ticket lifetime obtained by the Kerberos client may be larger than the 
> maximum set on the KDC
> -
>
> Key: DIRKRB-761
> URL: https://issues.apache.org/jira/browse/DIRKRB-761
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2
>Reporter: Jichao Wang
>Priority: Major
> Fix For: 2.0.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The ticket lifetime obtained by the Kerberos client may be greater than the 
> maximum lifetime configured on the KDC (maximum_ticket_lifetime)
> The contents of kdc.conf are as follows:
> {code:java}
> [kdcdefaults]
>   kdc_host = krb-wjc-kerberos-0
>   kdc_udp_port = 88
>   kdc_tcp_port = 88
>   kdc_realm = HADOOP.COM
>   encryption_types = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
>   preauth_required = false
>   maximum_renewable_lifetime = 0
>   maximum_ticket_lifetime = 86400
>   minimum_ticket_lifetime = 0 {code}
> Based on the above configuration, the maximum ticket lifetime obtained by the 
> Kerberos client should be 1 day. However, when I use the following krb5.conf 
> and methods to obtain the ticket, the lifetime of the ticket is 3 days, which 
> is larger than the maximum set on KDC of 1 day.
> The contents of krb5.conf are as follows:
> {code:java}
> [libdefaults]
>  dns_lookup_realm = false
>  dns_lookup_kdc = false
>  ticket_lifetime = 72h
>  renew_lifetime = 0
>  forwardable = false
>  renewable = false
>  rdns = false
>  default_realm = HADOOP.COM
>  default_ccache_name = /tmp/krb5cc_%{uid}
>  udp_preference_limit = 1
> [realms]
>  HADOOP.COM = {
>   kdc = krb-wjc-kerberos-0
>  } {code}
> First install the Kerberos client on the Centos7 operating system by running 
> the following command:
> {code:java}
> yum install -y krb5-devel krb5-workstation {code}
> Then use kinit to get the ticket from KDC and use the klist command to view 
> the ticket:
> {code:java}
> [root@localhost wjc]# kinit had...@hadoop.com
> Password for had...@hadoop.com:
> [root@localhost wjc]# klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: had...@hadoop.com
> Valid starting       Expires              Service principal
> 12/03/2022 16:44:10  12/06/2022 16:44:10  krbtgt/hadoop@hadoop.com
>         renew until 12/03/2022 16:44:10 {code}
> We can see that the lifetime of the Kerberos ticket is 3 days, which is 
> larger than the 1 day set in kdc.conf. This may cause security risks.
> So I think this is a bug.
> Here's how I fix it:
> Add a maximum life cycle to the condition of the if statement at 
> _org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java:173_ to 
> ensure that the ticket lifetime obtained by the client is not greater than 
> the maximum lifetime configured on the KDC.
> {code:java}
> Index: 
> kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===
> diff --git 
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
>  
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
> --- 
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
>     (revision 8cdcd544d14af1f876e3bbb16c959f30de79577d)
> +++ 
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/TicketIssuer.java
>     (revision 242ef1024a66169516e636030c1e720a94f35ef1)
> @@ -169,8 +169,9 @@
>          }
>  
>          KerberosTime krbEndTime = request.getReqBody().getTill();
> -        if (krbEndTime == null || krbEndTime.getTime() == 0) {
> -            krbEndTime = 
> krbStartTime.extend(config.getMaximumTicketLifetime() * 1000);
> +        KerberosTime maxEndTime = 
> krbStartTime.extend(config.getMaximumTicketLifetime() * 1000);
> +        if (krbEndTime == null || krbEndTime.getTime() == 0 || 
> krbEndTime.greaterThan(maxEndTime)) {
> +            krbEndTime = maxEndTime;
>          } else if (krbStartTime.greaterThan(krbEndTime)) {
>              throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID);
>          }{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-762) The AS request appears with an NPE when preauth_required is set to false

2022-12-18 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-762:


[~wjc920] What is the stacktrace of the NPE? I don't see off-hand how your PR 
is substantially different from the existing code.

> The AS request appears with an NPE when preauth_required is set to false
> 
>
> Key: DIRKRB-762
> URL: https://issues.apache.org/jira/browse/DIRKRB-762
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.1, 2.0.2
>Reporter: Jichao Wang
>Priority: Major
> Fix For: 2.0.3
>
>
> If change the value of preauth_required in the kdc.conf file to false, then 
> using the following code to access the KDC causes an NPE error.
> {code:java}
> // Run on JDK8 or JDK11
> public class Test {
>     public static void main(String[] args) throws Exception {
>         LoginContext lc = new LoginContext("SampleClient",
>                 new Subject(),
>                 null,
>                 new CustomConfiguration("had...@hadoop.com", 
> "/root/wjc/hadoop.keytab"));
>         lc.login();
>         System.out.println(lc.getSubject().toString());
>     }
> } {code}
> Here is a fix to the problem:
> {code:java}
> Index: 
> kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/KdcRequest.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===
> diff --git 
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/KdcRequest.java
>  
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/KdcRequest.java
> --- 
> a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/KdcRequest.java
>     (revision 03784fcde8e94fedbe789606d2f328104c20b33f)
> +++ 
> b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server/request/KdcRequest.java
>     (date 1670208307220)
> @@ -678,11 +678,13 @@
>          }
>  
>          PaData preAuthData = request.getPaData();
> -        if (isPreauthRequired() && (preAuthData == null || 
> preAuthData.isEmpty())) {
> -            LOG.info("The preauth data is empty.");
> -            KrbError krbError = makePreAuthenticationError(kdcContext, 
> request,
> -                KrbErrorCode.KDC_ERR_PREAUTH_REQUIRED, false);
> -            throw new KdcRecoverableException(krbError);
> +        if (isPreauthRequired()) {
> +            if (preAuthData == null || preAuthData.isEmpty()) {
> +                LOG.info("The preauth data is empty.");
> +                KrbError krbError = makePreAuthenticationError(kdcContext, 
> request,
> +                        KrbErrorCode.KDC_ERR_PREAUTH_REQUIRED, false);
> +                throw new KdcRecoverableException(krbError);
> +            }
>          } else {
>              getPreauthHandler().verify(this, preAuthData);
>          }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-759) Multithreading issue in 2.0.2 version during generation of credential cache

2022-10-20 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-759:


Can you attach the code sample please?

> Multithreading issue in 2.0.2 version during generation of credential cache
> ---
>
> Key: DIRKRB-759
> URL: https://issues.apache.org/jira/browse/DIRKRB-759
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.2
> Environment: prod
>Reporter: Vimal
>Priority: Major
>
> we are trying to use 2.0.2 version.
> trying to generate credential cache.
> under heavy load requestoptions in KdcRequest class is shared between two 
> threads and one thread is trying to look for the client key in another 
> threads keytab.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-759) Multithreading issue in 2.0.2 version during generation of credential cache

2022-10-20 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-759:


Yes but how are you using the Kerby API exactly? What are you calling to 
reproduce the scenario?

> Multithreading issue in 2.0.2 version during generation of credential cache
> ---
>
> Key: DIRKRB-759
> URL: https://issues.apache.org/jira/browse/DIRKRB-759
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.2
> Environment: prod
>Reporter: Vimal
>Priority: Major
>
> we are trying to use 2.0.2 version.
> trying to generate credential cache.
> under heavy load requestoptions in KdcRequest class is shared between two 
> threads and one thread is trying to look for the client key in another 
> threads keytab.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-759) Multithreading issue in 2.0.2 version during generation of credential cache

2022-10-20 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-759:


Can you share the Kerby client code that you are using?

> Multithreading issue in 2.0.2 version during generation of credential cache
> ---
>
> Key: DIRKRB-759
> URL: https://issues.apache.org/jira/browse/DIRKRB-759
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.2
> Environment: prod
>Reporter: Vimal
>Priority: Major
>
> we are trying to use 2.0.2 version.
> trying to generate credential cache.
> under heavy load requestoptions in KdcRequest class is shared between two 
> threads and one thread is trying to look for the client key in another 
> threads keytab.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-760) The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a vulnerability

2022-09-30 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-760:


It appears xnio is not used at all in kerb-common (only in kerb-admin), so I 
removed it from that module.

> The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a 
> vulnerability
> --
>
> Key: DIRKRB-760
> URL: https://issues.apache.org/jira/browse/DIRKRB-760
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Albert Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>
> *org.apache.kerby:kerb-common:jar:2.0.2* has a dependency library 
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final*.
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final* has a vulnerability CVE-2022-0084 
> which is fixed in *3.8.8.Final*.
> Can we upgrade the dependency to *3.8.8.Final*? Or, can we confirm that 
> *org.apache.kerby:kerb-common:jar:2.0.2* does not use the impact method of 
> *org.jboss.xnio:xnio-api:jar:3.8.4*?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-759) Multithreading issue in 2.0.2 version during generation of credential cache

2022-09-27 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-759:


Can you provide more information on how to reproduce and why it only manifests 
under heavy load?

> Multithreading issue in 2.0.2 version during generation of credential cache
> ---
>
> Key: DIRKRB-759
> URL: https://issues.apache.org/jira/browse/DIRKRB-759
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.0, 2.0.2
> Environment: prod
>Reporter: Vimal
>Priority: Major
>
> we are trying to use 2.0.2 version.
> trying to generate credential cache.
> under heavy load requestoptions in KdcRequest class is shared between two 
> threads and one thread is trying to look for the client key in another 
> threads keytab.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Commented] (DIRKRB-760) The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a vulnerability

2022-09-27 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-760:


Sorry, no release date yet. There haven't been many changes since 2.0.2.

> The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a 
> vulnerability
> --
>
> Key: DIRKRB-760
> URL: https://issues.apache.org/jira/browse/DIRKRB-760
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Albert Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>
> *org.apache.kerby:kerb-common:jar:2.0.2* has a dependency library 
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final*.
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final* has a vulnerability CVE-2022-0084 
> which is fixed in *3.8.8.Final*.
> Can we upgrade the dependency to *3.8.8.Final*? Or, can we confirm that 
> *org.apache.kerby:kerb-common:jar:2.0.2* does not use the impact method of 
> *org.jboss.xnio:xnio-api:jar:3.8.4*?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Assigned] (DIRKRB-760) The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a vulnerability

2022-09-26 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRKRB-760:
--

Assignee: Colm O hEigeartaigh

> The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a 
> vulnerability
> --
>
> Key: DIRKRB-760
> URL: https://issues.apache.org/jira/browse/DIRKRB-760
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Albert Wang
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.3
>
>
> *org.apache.kerby:kerb-common:jar:2.0.2* has a dependency library 
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final*.
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final* has a vulnerability CVE-2022-0084 
> which is fixed in *3.8.8.Final*.
> Can we upgrade the dependency to *3.8.8.Final*? Or, can we confirm that 
> *org.apache.kerby:kerb-common:jar:2.0.2* does not use the impact method of 
> *org.jboss.xnio:xnio-api:jar:3.8.4*?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Resolved] (DIRKRB-760) The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a vulnerability

2022-09-26 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-760.

Fix Version/s: 2.0.3
   Resolution: Fixed

> The dependency library org.jboss.xnio:xnio-api:jar:3.8.4.Final has a 
> vulnerability
> --
>
> Key: DIRKRB-760
> URL: https://issues.apache.org/jira/browse/DIRKRB-760
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.2
>Reporter: Albert Wang
>Priority: Major
> Fix For: 2.0.3
>
>
> *org.apache.kerby:kerb-common:jar:2.0.2* has a dependency library 
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final*.
> *org.jboss.xnio:xnio-api:jar:3.8.4.Final* has a vulnerability CVE-2022-0084 
> which is fixed in *3.8.8.Final*.
> Can we upgrade the dependency to *3.8.8.Final*? Or, can we confirm that 
> *org.apache.kerby:kerb-common:jar:2.0.2* does not use the impact method of 
> *org.jboss.xnio:xnio-api:jar:3.8.4*?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRSERVER-2341) Apache DS stops serving requests after error

2022-07-14 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRSERVER-2341:
---
Fix Version/s: (was: 2.0.0.AM26)

> Apache DS stops serving requests after error
> 
>
> Key: DIRSERVER-2341
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2341
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: jdbm
>Affects Versions: 2.0.0.AM26
> Environment: Apache DS 2.0.0 AM 26 running over RHEL 7.8 and Oracle 
> JDK 1.8.0_241-b07.
>Reporter: Andrea Campana
>Priority: Major
>  Labels: ERR_554, bug
>
> Hi everybody,
> today we had another issues with Apache DS on a production environment.
> In the morning, while the system was being loaded (every morning we load new 
> users into the system) we had the following error in the logs:
>  
> @
>  
> {code:java}
> [05:04:41] WARN [org.apache.directory.server.ldap.LdapProtocolHandler] - 
> Unexpected exception forcing session to close: sending disconnect notice to 
> client.
> java.lang.Error: ERR_554 double get for block 159java.lang.Error: ERR_554 
> double get for block 159 at jdbm.recman.RecordFile.get(RecordFile.java:185) 
> at jdbm.recman.PhysicalRowIdManager.fetch(PhysicalRowIdManager.java:128) at 
> jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:323) at 
> jdbm.btree.BPage.loadBPage(BPage.java:949) at 
> jdbm.btree.BPage.childBPage(BPage.java:938) at 
> jdbm.btree.BPage.insert(BPage.java:380) at 
> jdbm.btree.BPage.insert(BPage.java:381) at 
> jdbm.btree.BPage.insert(BPage.java:381) at 
> jdbm.btree.BTree.insert(BTree.java:302) at 
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.put(JdbmTable.java:541)
>  at 
> org.apache.directory.server.ldap.replication.provider.ReplicaEventLog.log(ReplicaEventLog.java:176)
>  at 
> org.apache.directory.server.ldap.replication.provider.SyncReplSearchListener.entryAdded(SyncReplSearchListener.java:224)
>  at 
> org.apache.directory.server.core.event.EventInterceptor.fire(EventInterceptor.java:131)
>  at 
> org.apache.directory.server.core.event.EventInterceptor.add(EventInterceptor.java:267)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  at 
> org.apache.directory.server.core.subtree.SubentryInterceptor.add(SubentryInterceptor.java:1034)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  at 
> org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.add(CollectiveAttributeInterceptor.java:138)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  at 
> org.apache.directory.server.core.operational.OperationalAttributeInterceptor.add(OperationalAttributeInterceptor.java:327)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  at 
> org.apache.directory.server.core.schema.SchemaInterceptor.add(SchemaInterceptor.java:1132)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  at 
> org.apache.directory.server.core.hash.ConfigurableHashingInterceptor.add(ConfigurableHashingInterceptor.java:91)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  at 
> org.apache.directory.server.core.exception.ExceptionInterceptor.add(ExceptionInterceptor.java:185)
>  at 
> org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:341)
>  
> {code}
>  
>  
> {{The problem is that after this error Apache DS stopped serving requests, 
> the only solution we had was to stop the server and restart it.}}
>  
> {{Is there any available fix or workaround for this issue?}}
>  
> {{Please help, thanks in advance and best regards,}}
> {{Andrea}}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Updated] (DIRSERVER-2364) How to ApacheDS Sync with Active Directory

2022-07-14 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRSERVER-2364:
---
Fix Version/s: (was: 2.0.0.AM26)

> How to ApacheDS Sync with Active Directory
> --
>
> Key: DIRSERVER-2364
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2364
> Project: Directory ApacheDS
>  Issue Type: Improvement
>  Components: migration
>Affects Versions: 2.0.0.AM26
>Reporter: pasit chatcharoenkit
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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



[jira] [Closed] (DIRKRB-745) Add ktadd cmd for remote admin tool

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-745.
--

> Add ktadd cmd for remote admin tool
> ---
>
> Key: DIRKRB-745
> URL: https://issues.apache.org/jira/browse/DIRKRB-745
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> ktadd/xst is a very important function, we need to add it to the remote 
> kadmin tool



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Closed] (DIRKRB-751) Fix remote kadmin sasl negotiation

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-751.
--

> Fix remote kadmin sasl negotiation
> --
>
> Key: DIRKRB-751
> URL: https://issues.apache.org/jira/browse/DIRKRB-751
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.1.0, 2.0.2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> At present, remote kadmin's sasl handshake has some problems. As long as the 
> server handshake is successful once, the client will always be able to pass 
> the sasl handshake. I modified the sasl handshake of remote kadmin according 
> to the sasl handshake logic of hadoop datanode.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Closed] (DIRKRB-757) CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-757.
--

> CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1
> 
>
> Key: DIRKRB-757
> URL: https://issues.apache.org/jira/browse/DIRKRB-757
> Project: Directory Kerberos
>  Issue Type: Bug
>  Components: has-project
>Affects Versions: 2.0.1
>Reporter: Thamindu Jayawickrama
>Priority: Major
> Fix For: 2.0.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> *Kerby asn1 2.0.1* uses the *junit 4.13* version which has a direct 
> vulnerability of CVE-2020-15250.
> [https://mvnrepository.com/artifact/org.apache.kerby/kerby-asn1/2.0.1]
> The project has been already updated with the [junit version 
> 4.13.2|https://mvnrepository.com/artifact/junit/junit/4.13.2] which doesn't 
> have any detected vulnerabilities.
> [https://github.com/apache/directory-kerby/blob/trunk/pom.xml#L56]
>  
> Can we expect a release with the updated junit version?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Closed] (DIRKRB-746) Verify kadmin principal in HAS remote kadmin tool

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-746.
--

> Verify kadmin principal in HAS remote kadmin tool
> -
>
> Key: DIRKRB-746
> URL: https://issues.apache.org/jira/browse/DIRKRB-746
> Project: Directory Kerberos
>  Issue Type: Improvement
>  Components: has-project
>Affects Versions: 2.0.1
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Currently, the remote kadmin tool of HAS does not limit the principal, 
> resulting in all legal keytabs that can use the remote kadmin tool through 
> authentication. The remote kadmin tool  should only allow the principal of 
> kadmin



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Closed] (DIRKRB-748) Need to replace KDC host when initKrb5conf generates krb5.conf

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-748.
--

> Need to replace KDC host when initKrb5conf generates krb5.conf
> --
>
> Key: DIRKRB-748
> URL: https://issues.apache.org/jira/browse/DIRKRB-748
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> KerbyAdminServer and RemoteAdminClientTool generate a krb5.conf file in conf 
> dir. However, the KDC host in the template file is always localhost. When the 
> RemoteAdminClientTool is used remotely, the KDC host needs to use the real 
> KDC host instead of localhost.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Closed] (DIRKRB-740) Support HA LDAP backend

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-740.
--

> Support HA LDAP backend
> ---
>
> Key: DIRKRB-740
> URL: https://issues.apache.org/jira/browse/DIRKRB-740
> Project: Directory Kerberos
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: wenxuanguan
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Closed] (DIRKRB-758) No way to specify conf dir for klist

2022-05-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh closed DIRKRB-758.
--

> No way to specify conf dir for klist
> 
>
> Key: DIRKRB-758
> URL: https://issues.apache.org/jira/browse/DIRKRB-758
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.2
>
>
> The klist tool doesn't give an option to specify the conf dir, like the kinit 
> tool does. It hard-codes the conf dir to /etc.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Updated] (DIRKRB-754) KrbClient.requestTgt(principal, password) receive PREAUTH_FAILED (MIT Kerbveros)

2022-05-04 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-754:
---
Fix Version/s: (was: 2.0.1)

> KrbClient.requestTgt(principal, password) receive PREAUTH_FAILED (MIT 
> Kerbveros)
> 
>
> Key: DIRKRB-754
> URL: https://issues.apache.org/jira/browse/DIRKRB-754
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Red Hat Enterprise Linux7.7, krb5-server.x86_64 
> 1.15.1-37.el7_6
>Reporter: zhanghw
>Priority: Major
>
> public static void main(String[] args) {
>     String principal = "lob2us...@dev.mydomain.com";
>     String password = "12345678";
>     KrbConfig krbConfig = new KrbConfig();
>     krbConfig.setString(KrbConfigKey.KDC_HOST, "kdc.mydomain.com");
>     krbConfig.setString(KrbConfigKey.KDC_REALM,"DEV.MYDOMAIN.COM");
>     krbConfig.setString(KrbConfigKey.PERMITTED_ENCTYPES, 
> "aes256-cts-hmac-sha1-96");
>     KrbClient krbClient = new KrbClient(krbConfig);
>     try {
>         krbClient.init();
>         TgtTicket tgt1 = krbClient.requestTgt(principal, password);
>     } catch (KrbException ex) {
>         ex.printStackTrace();
>     }
> }
>  
> krb5's error message:
> krb5kdc[1925](info): preauth (encrypted_timestamp) verify failure: 
> Preauthentication failed



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Resolved] (DIRKRB-758) No way to specify conf dir for klist

2022-04-26 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-758.

Resolution: Fixed

> No way to specify conf dir for klist
> 
>
> Key: DIRKRB-758
> URL: https://issues.apache.org/jira/browse/DIRKRB-758
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.2
>
>
> The klist tool doesn't give an option to specify the conf dir, like the kinit 
> tool does. It hard-codes the conf dir to /etc.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Created] (DIRKRB-758) No way to specify conf dir for klist

2022-04-26 Thread Colm O hEigeartaigh (Jira)
Colm O hEigeartaigh created DIRKRB-758:
--

 Summary: No way to specify conf dir for klist
 Key: DIRKRB-758
 URL: https://issues.apache.org/jira/browse/DIRKRB-758
 Project: Directory Kerberos
  Issue Type: Bug
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 2.0.2


The klist tool doesn't give an option to specify the conf dir, like the kinit 
tool does. It hard-codes the conf dir to /etc.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Updated] (DIRKRB-757) CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1

2022-04-21 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-757:
---
Fix Version/s: 2.0.2

> CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1
> 
>
> Key: DIRKRB-757
> URL: https://issues.apache.org/jira/browse/DIRKRB-757
> Project: Directory Kerberos
>  Issue Type: Bug
>  Components: has-project
>Affects Versions: 2.0.1
>Reporter: Thamindu Jayawickrama
>Priority: Major
> Fix For: 2.0.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> *Kerby asn1 2.0.1* uses the *junit 4.13* version which has a direct 
> vulnerability of CVE-2020-15250.
> [https://mvnrepository.com/artifact/org.apache.kerby/kerby-asn1/2.0.1]
> The project has been already updated with the [junit version 
> 4.13.2|https://mvnrepository.com/artifact/junit/junit/4.13.2] which doesn't 
> have any detected vulnerabilities.
> [https://github.com/apache/directory-kerby/blob/trunk/pom.xml#L56]
>  
> Can we expect a release with the updated junit version?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Resolved] (DIRKRB-757) CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1

2022-04-21 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-757.

Resolution: Fixed

> CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1
> 
>
> Key: DIRKRB-757
> URL: https://issues.apache.org/jira/browse/DIRKRB-757
> Project: Directory Kerberos
>  Issue Type: Bug
>  Components: has-project
>Affects Versions: 2.0.1
>Reporter: Thamindu Jayawickrama
>Priority: Major
> Fix For: 2.0.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> *Kerby asn1 2.0.1* uses the *junit 4.13* version which has a direct 
> vulnerability of CVE-2020-15250.
> [https://mvnrepository.com/artifact/org.apache.kerby/kerby-asn1/2.0.1]
> The project has been already updated with the [junit version 
> 4.13.2|https://mvnrepository.com/artifact/junit/junit/4.13.2] which doesn't 
> have any detected vulnerabilities.
> [https://github.com/apache/directory-kerby/blob/trunk/pom.xml#L56]
>  
> Can we expect a release with the updated junit version?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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



[jira] [Commented] (DIRKRB-757) CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1

2022-03-22 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-757:


Isn't it just a test dependency?

 
{code:java}
[INFO] org.apache.kerby:kerby-asn1:jar:2.0.2-SNAPSHOT
[INFO] +- junit:junit:jar:4.13.2:test {code}

> CVE-2020-15250 vulnerability from the junit dependency in Kerby ASN1
> 
>
> Key: DIRKRB-757
> URL: https://issues.apache.org/jira/browse/DIRKRB-757
> Project: Directory Kerberos
>  Issue Type: Bug
>  Components: has-project
>Affects Versions: 2.0.1
>Reporter: Thamindu Jayawickrama
>Priority: Major
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> *Kerby asn1 2.0.1* uses the *junit 4.13* version which has a direct 
> vulnerability of CVE-2020-15250.
> [https://mvnrepository.com/artifact/org.apache.kerby/kerby-asn1/2.0.1]
> The project has been already updated with the [junit version 
> 4.13.2|https://mvnrepository.com/artifact/junit/junit/4.13.2] which doesn't 
> have any detected vulnerabilities.
> [https://github.com/apache/directory-kerby/blob/trunk/pom.xml#L56]
>  
> Can we expect a release with the updated junit version?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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



[jira] [Resolved] (DIRSERVER-2330) StartTlsHandler and LdapsInitializer use NoVerificationTrustManager

2021-05-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2330.

Resolution: Fixed

> StartTlsHandler and LdapsInitializer use NoVerificationTrustManager
> ---
>
> Key: DIRSERVER-2330
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2330
> Project: Directory ApacheDS
>  Issue Type: Task
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> StartTlsHandler and LdapsInitializer use NoVerificationTrustManager. Instead 
> they should get the TrustManagers from the LdapServer, and we should have a 
> new annotation in CreateLdapServer to set the TrustManager classes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRSERVER-2329) Replication trust manager improvements

2021-05-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2329.

Resolution: Fixed

> Replication trust manager improvements
> --
>
> Key: DIRSERVER-2329
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2329
> Project: Directory ApacheDS
>  Issue Type: Task
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> There are some improvements that should be made regarding trust manager 
> configuration for Replication:
>  # In ReplicationTrustManager, the static block is not initialized before the 
> constructor (at least in the tests), leading to a NPE.
>  # SyncReplConfiguration defaults to NoVerificationTrustManager, which is not 
> secure, even though this is inconsistent with the value for 
> strictCertVerification (true)
>  # The CreateConsumer annotation has a trustManager setting which is not used 
> anywhere
>  # The ServerAnnotationProcessor does not wire the value for 
> CreateConsumer.{color:#00627a}strictCertVerification{color}()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DIRSERVER-2338) Using a static IV in symmetric encryption with CBC mode

2021-05-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRSERVER-2338:
--

Assignee: Colm O hEigeartaigh

> Using a static IV in symmetric encryption with CBC mode
> ---
>
> Key: DIRSERVER-2338
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2338
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Ya Xiao
>Assignee: Colm O hEigeartaigh
>Priority: Major
>  Labels: patch, security
>
> *Vulnerability Description*
> In file 
> [directory-server/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/DesCbcCrcEncryption.java|[https://github.com/apache/directory-server/blob/master/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/DesCbcCrcEncryption.java],]
>  a hardcoded IV (at Line 161) is used to initialize the cipher (at Line 165, 
> Line 169).
> *Security Impact:*
> The IV of CBC mode is expected to be random. The static IV makes the 
> resulting ciphertext much more predictable and susceptible to a dictionary 
> attack.
> *Useful Resources*:
> [https://cwe.mitre.org/data/definitions/338.html|https://cwe.mitre.org/data/definitions/329.html]
> *Solution we suggest*
> Generate the IV bytes through SecureRandom.
> *Please share with us your opinions/comments if there is any*
> Is the bug report helpful?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRSERVER-2338) Using a static IV in symmetric encryption with CBC mode

2021-05-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2338.

Resolution: Fixed

> Using a static IV in symmetric encryption with CBC mode
> ---
>
> Key: DIRSERVER-2338
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2338
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Ya Xiao
>Assignee: Colm O hEigeartaigh
>Priority: Major
>  Labels: patch, security
> Fix For: 2.0.0.AM27
>
>
> *Vulnerability Description*
> In file 
> [directory-server/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/DesCbcCrcEncryption.java|[https://github.com/apache/directory-server/blob/master/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/DesCbcCrcEncryption.java],]
>  a hardcoded IV (at Line 161) is used to initialize the cipher (at Line 165, 
> Line 169).
> *Security Impact:*
> The IV of CBC mode is expected to be random. The static IV makes the 
> resulting ciphertext much more predictable and susceptible to a dictionary 
> attack.
> *Useful Resources*:
> [https://cwe.mitre.org/data/definitions/338.html|https://cwe.mitre.org/data/definitions/329.html]
> *Solution we suggest*
> Generate the IV bytes through SecureRandom.
> *Please share with us your opinions/comments if there is any*
> Is the bug report helpful?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DIRSERVER-2338) Using a static IV in symmetric encryption with CBC mode

2021-05-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRSERVER-2338:
---
Fix Version/s: 2.0.0.AM27

> Using a static IV in symmetric encryption with CBC mode
> ---
>
> Key: DIRSERVER-2338
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2338
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Ya Xiao
>Assignee: Colm O hEigeartaigh
>Priority: Major
>  Labels: patch, security
> Fix For: 2.0.0.AM27
>
>
> *Vulnerability Description*
> In file 
> [directory-server/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/DesCbcCrcEncryption.java|[https://github.com/apache/directory-server/blob/master/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/crypto/encryption/DesCbcCrcEncryption.java],]
>  a hardcoded IV (at Line 161) is used to initialize the cipher (at Line 165, 
> Line 169).
> *Security Impact:*
> The IV of CBC mode is expected to be random. The static IV makes the 
> resulting ciphertext much more predictable and susceptible to a dictionary 
> attack.
> *Useful Resources*:
> [https://cwe.mitre.org/data/definitions/338.html|https://cwe.mitre.org/data/definitions/329.html]
> *Solution we suggest*
> Generate the IV bytes through SecureRandom.
> *Please share with us your opinions/comments if there is any*
> Is the bug report helpful?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (DIR-337) Spurious file on download server

2021-02-16 Thread Colm O hEigeartaigh (Jira)


[ 
https://issues.apache.org/jira/browse/DIR-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17285659#comment-17285659
 ] 

Colm O hEigeartaigh commented on DIR-337:
-

I removed the file

> Spurious file on download server
> 
>
> Key: DIR-337
> URL: https://issues.apache.org/jira/browse/DIR-337
> Project: Directory
>  Issue Type: Bug
>Reporter: Sebb
>Assignee: Emmanuel Lécharny
>Priority: Major
>
> The following file appears to have been uploaded by mistake:
> https://downloads.apache.org/directory/mavibot/dist/1.0.0-M8/mavibot-1.0.0-M8-bin.tar.gz.gpg
> It is a version of mavibot-1.0.0-M8-bin.tar.gz with built-in gpg signature.
> The ASF only uses detached ascii signatures (.asc) so this file should please 
> be removed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRSERVER-2328) CreateAuthenticator annotation trust manager improvements

2021-02-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2328.

Resolution: Fixed

> CreateAuthenticator annotation trust manager improvements
> -
>
> Key: DIRSERVER-2328
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2328
> Project: Directory ApacheDS
>  Issue Type: Task
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> There are two problems with the CreateAuthenticator annotation trust manager 
> configuration:
>  # delegateSslTrustManagerFQCN + delegateTlsTrustManagerFQCN default to 
> NoVerificationTrustManager, which is not secure.
>  # These values are not plugged through to the DelegatingAuthenticator, which 
> hard-codes NoVerificationTrustManager.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRKRB-751) Fix remote kadmin sasl negotiation

2020-11-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-751.

Resolution: Fixed

> Fix remote kadmin sasl negotiation
> --
>
> Key: DIRKRB-751
> URL: https://issues.apache.org/jira/browse/DIRKRB-751
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.1.0, 2.0.2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> At present, remote kadmin's sasl handshake has some problems. As long as the 
> server handshake is successful once, the client will always be able to pass 
> the sasl handshake. I modified the sasl handshake of remote kadmin according 
> to the sasl handshake logic of hadoop datanode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DIRKRB-751) Fix remote kadmin sasl negotiation

2020-11-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-751:
---
Fix Version/s: 2.0.2
   2.1.0

> Fix remote kadmin sasl negotiation
> --
>
> Key: DIRKRB-751
> URL: https://issues.apache.org/jira/browse/DIRKRB-751
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.1.0, 2.0.2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> At present, remote kadmin's sasl handshake has some problems. As long as the 
> server handshake is successful once, the client will always be able to pass 
> the sasl handshake. I modified the sasl handshake of remote kadmin according 
> to the sasl handshake logic of hadoop datanode.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRSERVER-2326) LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)

2020-10-12 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2326.

Resolution: Fixed

> LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)
> 
>
> Key: DIRSERVER-2326
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2326
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.0.AM26
> Environment: IBM Java 8
>Reporter: Josef Cacek
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> The LDAP server won't start on IBM JDK version 8 due to changes in Directory 
> Server AM26. The 
> {{org.apache.directory.server.core.security.CertificateUtil}} newly used to 
> load keystore imports internal {{sun.security.x509}} package classes. These 
> classes are not available on IBM JDK 8.
> h3. Stacktrace
> {code:java}
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
>   at 
> org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:421)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:328)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
>   at 
> org.apache.directory.server.core.integ.CreateLdapServerRule$2.evaluate(CreateLdapServerRule.java:112)
>   at 
> org.apache.directory.server.core.integ.CreateDsRule$2.evaluate(CreateDsRule.java:124)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: java.lang.ClassNotFoundException: 
> sun.security.x509.GeneralNameInterface
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
>   at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
>   ... 25 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Assigned] (DIRSERVER-2326) LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)

2020-10-12 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRSERVER-2326:
--

Assignee: Colm O hEigeartaigh

> LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)
> 
>
> Key: DIRSERVER-2326
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2326
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.0.AM26
> Environment: IBM Java 8
>Reporter: Josef Cacek
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> The LDAP server won't start on IBM JDK version 8 due to changes in Directory 
> Server AM26. The 
> {{org.apache.directory.server.core.security.CertificateUtil}} newly used to 
> load keystore imports internal {{sun.security.x509}} package classes. These 
> classes are not available on IBM JDK 8.
> h3. Stacktrace
> {code:java}
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
>   at 
> org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:421)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:328)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
>   at 
> org.apache.directory.server.core.integ.CreateLdapServerRule$2.evaluate(CreateLdapServerRule.java:112)
>   at 
> org.apache.directory.server.core.integ.CreateDsRule$2.evaluate(CreateDsRule.java:124)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: java.lang.ClassNotFoundException: 
> sun.security.x509.GeneralNameInterface
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
>   at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
>   ... 25 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRKRB-740) Support HA LDAP backend

2020-10-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRKRB-740.

Resolution: Fixed

> Support HA LDAP backend
> ---
>
> Key: DIRKRB-740
> URL: https://issues.apache.org/jira/browse/DIRKRB-740
> Project: Directory Kerberos
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: wenxuanguan
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DIRKRB-740) Support HA LDAP backend

2020-10-09 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-740:
---
Fix Version/s: 2.0.2

> Support HA LDAP backend
> ---
>
> Key: DIRKRB-740
> URL: https://issues.apache.org/jira/browse/DIRKRB-740
> Project: Directory Kerberos
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: wenxuanguan
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DIRSERVER-2326) LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)

2020-09-11 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRSERVER-2326:
---
Fix Version/s: 2.0.0.AM27

> LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)
> 
>
> Key: DIRSERVER-2326
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2326
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.0.AM26
> Environment: IBM Java 8
>Reporter: Josef Cacek
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> The LDAP server won't start on IBM JDK version 8 due to changes in Directory 
> Server AM26. The 
> {{org.apache.directory.server.core.security.CertificateUtil}} newly used to 
> load keystore imports internal {{sun.security.x509}} package classes. These 
> classes are not available on IBM JDK 8.
> h3. Stacktrace
> {code:java}
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
>   at 
> org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:421)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:328)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
>   at 
> org.apache.directory.server.core.integ.CreateLdapServerRule$2.evaluate(CreateLdapServerRule.java:112)
>   at 
> org.apache.directory.server.core.integ.CreateDsRule$2.evaluate(CreateDsRule.java:124)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: java.lang.ClassNotFoundException: 
> sun.security.x509.GeneralNameInterface
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
>   at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
>   ... 25 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Commented] (DIRSERVER-2326) LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)

2020-09-11 Thread Colm O hEigeartaigh (Jira)


[ 
https://issues.apache.org/jira/browse/DIRSERVER-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194043#comment-17194043
 ] 

Colm O hEigeartaigh commented on DIRSERVER-2326:


IMO it makes sense to merge the bcpkix PR, as we are already using BouncyCastle 
in core anyway.

> LDAP server doesn't start on IBM JDK 8 (NoClassDefFound)
> 
>
> Key: DIRSERVER-2326
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2326
> Project: Directory ApacheDS
>  Issue Type: Bug
>  Components: core
>Affects Versions: 2.0.0.AM26
> Environment: IBM Java 8
>Reporter: Josef Cacek
>Priority: Major
>
> The LDAP server won't start on IBM JDK version 8 due to changes in Directory 
> Server AM26. The 
> {{org.apache.directory.server.core.security.CertificateUtil}} newly used to 
> load keystore imports internal {{sun.security.x509}} package classes. These 
> classes are not available on IBM JDK 8.
> h3. Stacktrace
> {code:java}
> java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface
>   at 
> org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:421)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:328)
>   at 
> org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
>   at 
> org.apache.directory.server.core.integ.CreateLdapServerRule$2.evaluate(CreateLdapServerRule.java:112)
>   at 
> org.apache.directory.server.core.integ.CreateDsRule$2.evaluate(CreateDsRule.java:124)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
>   at 
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
> Caused by: java.lang.ClassNotFoundException: 
> sun.security.x509.GeneralNameInterface
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
>   at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:889)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
>   ... 25 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Created] (DIRSERVER-2330) StartTlsHandler and LdapsInitializer use NoVerificationTrustManager

2020-09-10 Thread Colm O hEigeartaigh (Jira)
Colm O hEigeartaigh created DIRSERVER-2330:
--

 Summary: StartTlsHandler and LdapsInitializer use 
NoVerificationTrustManager
 Key: DIRSERVER-2330
 URL: https://issues.apache.org/jira/browse/DIRSERVER-2330
 Project: Directory ApacheDS
  Issue Type: Task
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 2.0.0.AM27


StartTlsHandler and LdapsInitializer use NoVerificationTrustManager. Instead 
they should get the TrustManagers from the LdapServer, and we should have a new 
annotation in CreateLdapServer to set the TrustManager classes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Created] (DIRSERVER-2329) Replication trust manager improvements

2020-09-10 Thread Colm O hEigeartaigh (Jira)
Colm O hEigeartaigh created DIRSERVER-2329:
--

 Summary: Replication trust manager improvements
 Key: DIRSERVER-2329
 URL: https://issues.apache.org/jira/browse/DIRSERVER-2329
 Project: Directory ApacheDS
  Issue Type: Task
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 2.0.0.AM27


There are some improvements that should be made regarding trust manager 
configuration for Replication:
 # In ReplicationTrustManager, the static block is not initialized before the 
constructor (at least in the tests), leading to a NPE.
 # SyncReplConfiguration defaults to NoVerificationTrustManager, which is not 
secure, even though this is inconsistent with the value for 
strictCertVerification (true)
 # The CreateConsumer annotation has a trustManager setting which is not used 
anywhere
 # The ServerAnnotationProcessor does not wire the value for 
CreateConsumer.{color:#00627a}strictCertVerification{color}()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Created] (DIRSERVER-2328) CreateAuthenticator annotation trust manager improvements

2020-09-09 Thread Colm O hEigeartaigh (Jira)
Colm O hEigeartaigh created DIRSERVER-2328:
--

 Summary: CreateAuthenticator annotation trust manager improvements
 Key: DIRSERVER-2328
 URL: https://issues.apache.org/jira/browse/DIRSERVER-2328
 Project: Directory ApacheDS
  Issue Type: Task
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 2.0.0.AM27


There are two problems with the CreateAuthenticator annotation trust manager 
configuration:
 # delegateSslTrustManagerFQCN + delegateTlsTrustManagerFQCN default to 
NoVerificationTrustManager, which is not secure.
 # These values are not plugged through to the DelegatingAuthenticator, which 
hard-codes NoVerificationTrustManager.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Resolved] (DIRSERVER-2327) Add possibility to use custom ReplayCache implementation

2020-09-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh resolved DIRSERVER-2327.

Resolution: Fixed

> Add possibility to use custom ReplayCache implementation
> 
>
> Key: DIRSERVER-2327
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2327
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Josef Cacek
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> Add the possibility to configure the ReplayCache implementation (or disable 
> replay cache) in KDC.
> When the KdcServer is used in embedded tests, and tests run in parallel, they 
> intermittently fail with "Request is a replay (34) - Request is a replay".
> I saw the problematic behavior in JBoss AS testsuite:
> [https://issues.redhat.com/browse/JBPAPP-10974]
>  
> And also in Hazelcast Enterprise tests:
> [https://github.com/hazelcast/hazelcast-enterprise/issues/3646]
>  
> JBoss resolves it by injecting dummy ReplayCache implementation by using 
> reflection: [https://source.jboss.org/changelog/JBossAS6?cs=114679&_sscc=t]
>  
> We will probably disable parallel test execution in Hazelcast to workaround 
> it.
> It would be great to have a possibility to configure the implementing class 
> in the {{@CreateKdcServer annotation.}}
> h3. {{Stacktrace from a failing test}}
>  
> {{KrbException: Request is a replay (34) - Request is a replayKrbException: 
> Request is a replay (34) - Request is a replay at 
> java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:73) at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:250) 
> at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:261)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:308)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:126)
>  at 
> java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:458)
>  at 
> java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:695)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:265)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:196)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.createTokenCredentials(KerberosCredentialsFactory.java:163)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.lambda$0(KerberosCredentialsFactory.java:127)
>  at java.base/java.security.AccessController.doPrivileged(Native Method) at 
> java.base/javax.security.auth.Subject.doAs(Subject.java:361) at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:127)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:148)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.getKerberosCredentials(GssApiLoginModuleTest.java:169)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.testCutOffRealmFromName(GssApiLoginModuleTest.java:132)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:564) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:114)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:1)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.lang.Thread.run(Thread.java:844)Caused by: KrbException: 
> Identifier doesn't match expected value (906) at 
> java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.(TGSRep.java:60) 
> at java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:55) 
> ... 28 more}}{{ }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (DIRSERVER-2327) Add possibility to use custom ReplayCache implementation

2020-09-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRSERVER-2327:
---
Fix Version/s: 2.0.0.AM27

> Add possibility to use custom ReplayCache implementation
> 
>
> Key: DIRSERVER-2327
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2327
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Josef Cacek
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.0.0.AM27
>
>
> Add the possibility to configure the ReplayCache implementation (or disable 
> replay cache) in KDC.
> When the KdcServer is used in embedded tests, and tests run in parallel, they 
> intermittently fail with "Request is a replay (34) - Request is a replay".
> I saw the problematic behavior in JBoss AS testsuite:
> [https://issues.redhat.com/browse/JBPAPP-10974]
>  
> And also in Hazelcast Enterprise tests:
> [https://github.com/hazelcast/hazelcast-enterprise/issues/3646]
>  
> JBoss resolves it by injecting dummy ReplayCache implementation by using 
> reflection: [https://source.jboss.org/changelog/JBossAS6?cs=114679&_sscc=t]
>  
> We will probably disable parallel test execution in Hazelcast to workaround 
> it.
> It would be great to have a possibility to configure the implementing class 
> in the {{@CreateKdcServer annotation.}}
> h3. {{Stacktrace from a failing test}}
>  
> {{KrbException: Request is a replay (34) - Request is a replayKrbException: 
> Request is a replay (34) - Request is a replay at 
> java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:73) at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:250) 
> at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:261)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:308)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:126)
>  at 
> java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:458)
>  at 
> java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:695)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:265)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:196)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.createTokenCredentials(KerberosCredentialsFactory.java:163)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.lambda$0(KerberosCredentialsFactory.java:127)
>  at java.base/java.security.AccessController.doPrivileged(Native Method) at 
> java.base/javax.security.auth.Subject.doAs(Subject.java:361) at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:127)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:148)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.getKerberosCredentials(GssApiLoginModuleTest.java:169)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.testCutOffRealmFromName(GssApiLoginModuleTest.java:132)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:564) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:114)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:1)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.lang.Thread.run(Thread.java:844)Caused by: KrbException: 
> Identifier doesn't match expected value (906) at 
> java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.(TGSRep.java:60) 
> at java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:55) 
> ... 28 more}}{{ }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (DIRSERVER-2327) Add possibility to use custom ReplayCache implementation

2020-09-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh reassigned DIRSERVER-2327:
--

Assignee: Colm O hEigeartaigh

> Add possibility to use custom ReplayCache implementation
> 
>
> Key: DIRSERVER-2327
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2327
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Josef Cacek
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Add the possibility to configure the ReplayCache implementation (or disable 
> replay cache) in KDC.
> When the KdcServer is used in embedded tests, and tests run in parallel, they 
> intermittently fail with "Request is a replay (34) - Request is a replay".
> I saw the problematic behavior in JBoss AS testsuite:
> [https://issues.redhat.com/browse/JBPAPP-10974]
>  
> And also in Hazelcast Enterprise tests:
> [https://github.com/hazelcast/hazelcast-enterprise/issues/3646]
>  
> JBoss resolves it by injecting dummy ReplayCache implementation by using 
> reflection: [https://source.jboss.org/changelog/JBossAS6?cs=114679&_sscc=t]
>  
> We will probably disable parallel test execution in Hazelcast to workaround 
> it.
> It would be great to have a possibility to configure the implementing class 
> in the {{@CreateKdcServer annotation.}}
> h3. {{Stacktrace from a failing test}}
>  
> {{KrbException: Request is a replay (34) - Request is a replayKrbException: 
> Request is a replay (34) - Request is a replay at 
> java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:73) at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:250) 
> at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:261)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:308)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:126)
>  at 
> java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:458)
>  at 
> java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:695)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:265)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:196)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.createTokenCredentials(KerberosCredentialsFactory.java:163)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.lambda$0(KerberosCredentialsFactory.java:127)
>  at java.base/java.security.AccessController.doPrivileged(Native Method) at 
> java.base/javax.security.auth.Subject.doAs(Subject.java:361) at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:127)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:148)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.getKerberosCredentials(GssApiLoginModuleTest.java:169)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.testCutOffRealmFromName(GssApiLoginModuleTest.java:132)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:564) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:114)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:1)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.lang.Thread.run(Thread.java:844)Caused by: KrbException: 
> Identifier doesn't match expected value (906) at 
> java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.(TGSRep.java:60) 
> at java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:55) 
> ... 28 more}}{{ }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (DIRSERVER-2327) Add possibility to use custom ReplayCache implementation

2020-09-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRSERVER-2327:
---
Key: DIRSERVER-2327  (was: DIRKRB-744)
Project: Directory ApacheDS  (was: Directory Kerberos)

> Add possibility to use custom ReplayCache implementation
> 
>
> Key: DIRSERVER-2327
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2327
> Project: Directory ApacheDS
>  Issue Type: Improvement
>Reporter: Josef Cacek
>Priority: Major
>
> Add the possibility to configure the ReplayCache implementation (or disable 
> replay cache) in KDC.
> When the KdcServer is used in embedded tests, and tests run in parallel, they 
> intermittently fail with "Request is a replay (34) - Request is a replay".
> I saw the problematic behavior in JBoss AS testsuite:
> [https://issues.redhat.com/browse/JBPAPP-10974]
>  
> And also in Hazelcast Enterprise tests:
> [https://github.com/hazelcast/hazelcast-enterprise/issues/3646]
>  
> JBoss resolves it by injecting dummy ReplayCache implementation by using 
> reflection: [https://source.jboss.org/changelog/JBossAS6?cs=114679&_sscc=t]
>  
> We will probably disable parallel test execution in Hazelcast to workaround 
> it.
> It would be great to have a possibility to configure the implementing class 
> in the {{@CreateKdcServer annotation.}}
> h3. {{Stacktrace from a failing test}}
>  
> {{KrbException: Request is a replay (34) - Request is a replayKrbException: 
> Request is a replay (34) - Request is a replay at 
> java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:73) at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:250) 
> at 
> java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:261)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:308)
>  at 
> java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:126)
>  at 
> java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:458)
>  at 
> java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:695)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:265)
>  at 
> java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:196)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.createTokenCredentials(KerberosCredentialsFactory.java:163)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.lambda$0(KerberosCredentialsFactory.java:127)
>  at java.base/java.security.AccessController.doPrivileged(Native Method) at 
> java.base/javax.security.auth.Subject.doAs(Subject.java:361) at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:127)
>  at 
> com.hazelcast.security.impl.KerberosCredentialsFactory.newCredentials(KerberosCredentialsFactory.java:148)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.getKerberosCredentials(GssApiLoginModuleTest.java:169)
>  at 
> com.hazelcast.security.loginimpl.GssApiLoginModuleTest.testCutOffRealmFromName(GssApiLoginModuleTest.java:132)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:564) at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:114)
>  at 
> com.hazelcast.test.FailOnTimeoutStatement$CallableStatement.call(FailOnTimeoutStatement.java:1)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.lang.Thread.run(Thread.java:844)Caused by: KrbException: 
> Identifier doesn't match expected value (906) at 
> java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65) at 
> java.security.jgss/sun.security.krb5.internal.TGSRep.(TGSRep.java:60) 
> at java.security.jgss/sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:55) 
> ... 28 more}}{{ }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (DIRKRB-747) Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals

2020-09-08 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh commented on DIRKRB-747:


Could you submit a pull request to fix this issue, or contribute a test-case 
that shows where the problem is?

 

> Date encoding is buggy with JDK 15 and non-Arabic (Western) numerals
> 
>
> Key: DIRKRB-747
> URL: https://issues.apache.org/jira/browse/DIRKRB-747
> Project: Directory Kerberos
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Yang Wang
>Priority: Major
>
> Since JDK 9, 
> [CLDR|https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm#JSINT-GUID-AF5AECA7-07C1-4E7D-BC10-BC7E73DC6C7F]
>  has been the default Locale data. JDK 15 b23 
> [fixed|https://bugs.openjdk.java.net/browse/JDK-8244245] `DateTimeFormatter` 
> so that non-Arabic (Western) numerals are now correctly honored for date 
> digits. This means, instead of {{2020}}, it will be {{২০২০}} for Locale 
> {{mni-Beng-IN}} (Manipuri India Bangla) when CLDR provider is used (which is 
> default).
> In method 
> [{{Asn1GeneralizedTime#toBytes}}|https://github.com/apache/directory-kerby/blob/trunk/kerby-common/kerby-asn1/src/main/java/org/apache/kerby/asn1/type/Asn1GeneralizedTime.java#L83-L91],
>  a Date object is converted to string using {{SimpleDateFormat}} with system 
> Locale, then converted to bytes with {{StandardCharsets.US_ASCII}}. This 
> leads to erroneous byte representation if the system Locale has non-Arabic 
> (western) numerals and CLDR is in use. For example, {{২০২০}} is converted to 
> something like {{byte[]\{63, 63, 63, 63}}}. 
> These bytes are in turn encoded into {{KrbMessage}} and sent to the clients. 
> The JDK's Kerberos implementation [expects only ASCII 
> chars|https://github.com/openjdk/jdk15/blob/master/src/java.base/share/classes/sun/security/util/DerInputBuffer.java#L290-L308]
>  for date strings and hence throws an {{IOException}} when decoding the 
> message.
> The workaround is to pass {{-Djava.locale.providers=COMPAT}} to the JVM so 
> that it does not use the CLDR provider. This is non-ideal and also COMPAT is 
> [on its way out|https://bugs.openjdk.java.net/browse/JDK-8174269]. Therefore 
> it would great if this can be fixed within Kerby to ensure ASCII 
> representation is alwauys used when converting a Date to String. This is 
> plausible since the Kerberos spec also 
> [recognises|https://tools.ietf.org/html/rfc4120#section-5.2.1] it has issues 
> for full i18n support.
> I can confirm this issue exists for {{v1.1.1}}. I have not tested with 
> {{v2.0.1}}. But looking at the source code, it is very likely that the same 
> issue affects {{v2.0.1}} as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (DIRKRB-745) Add ktadd cmd for remote admin tool

2020-08-10 Thread Colm O hEigeartaigh (Jira)


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

Colm O hEigeartaigh updated DIRKRB-745:
---
Fix Version/s: 2.0.2

> Add ktadd cmd for remote admin tool
> ---
>
> Key: DIRKRB-745
> URL: https://issues.apache.org/jira/browse/DIRKRB-745
> Project: Directory Kerberos
>  Issue Type: Improvement
>Reporter: Jiayi Liu
>Assignee: Jiayi Liu
>Priority: Major
> Fix For: 2.0.2
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> ktadd/xst is a very important function, we need to add it to the remote 
> kadmin tool



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



  1   2   3   4   5   6   >