[jira] [Closed] (DIRKRB-773) jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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);
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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)
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)
[ 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)
[ 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
[ 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
[ 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)
[ 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)
[ 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
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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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