January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1369) FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.s... ] Martin Choma edited comment on ELY-1369 at 1/10/18 11:57 AM: ------------------------------------------------------------- Curl has [1]. There is some long-termly proposed patch for Firefox [2]. Customer using Python script - found one PR from Python world [3]. But yes this does not seem as priority for clients. Still there can be some in future. [1] https://github.com/curl/curl/pull/1934 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=472823 [3] https://github.com/httplib2/httplib2/pull/23 was (Author: mchoma): Curl has [1]. There is some long-termly proposed patch for Firefox. But yes this does not seem as priority for browser. Still there can be some in future. [1] https://github.com/curl/curl/pull/1934 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=472823 > FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant > -------------------------------------------------------------------------- > > Key: ELY-1369 > URL: https://issues.jboss.org/browse/ELY-1369 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.2.0.Beta11 > > > Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5]. > {code:java|title=DigestAuthenticationMechanism.java} > String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM)); > if (MD5.equals(algorithm) == false) { > throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm); > } > {code} > There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? > [1] https://issues.jboss.org/browse/ELY-286 > [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design > [3] https://tools.ietf.org/html/rfc2617 > [4] https://tools.ietf.org/html/rfc7616 > [5] https://access.redhat.com/support/cases/#/case/01761455 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1369) FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1369: ----------------------------------- Curl has [1]. There is some long-termly proposed patch for Firefox. But yes this does not seem as priority for browser. Still there can be some in future. [1] https://github.com/curl/curl/pull/1934 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=472823 > FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant > -------------------------------------------------------------------------- > > Key: ELY-1369 > URL: https://issues.jboss.org/browse/ELY-1369 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.2.0.Beta11 > > > Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5]. > {code:java|title=DigestAuthenticationMechanism.java} > String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM)); > if (MD5.equals(algorithm) == false) { > throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm); > } > {code} > There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? > [1] https://issues.jboss.org/browse/ELY-286 > [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design > [3] https://tools.ietf.org/html/rfc2617 > [4] https://tools.ietf.org/html/rfc7616 > [5] https://access.redhat.com/support/cases/#/case/01761455 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9610) Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.... ] Cheng Fang commented on WFLY-9610: ---------------------------------- this will be fixed to ensure a complete stop. See [JBERET-377|https://issues.jboss.org/browse/JBERET-377] Stop job execution with STARTING status before it's actually started > Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9610 > URL: https://issues.jboss.org/browse/WFLY-9610 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 9.0.1.Final > Environment: Cluster, standalone-full-ha > Reporter: Serg Pol > Assignee: Cheng Fang > > Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). > There are no any error nessages. > BatchJob is not started in this case according Log. > Any idea? Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1295: ----------------------------------- It is OK to ignore this. There is a way to setup external storage encrypted with proper SecretKey from supported keystore (JCEKS). > KeyStoreCredentialStoreTest fails on IBM JDK > -------------------------------------------- > > Key: ELY-1295 > URL: https://issues.jboss.org/browse/ELY-1295 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Peter Palaga > Assignee: Jan Kalina > Priority: Critical > Labels: ibm-java > > {code} > export JAVA_HOME=path/to/ibm/java8 > > $JAVA_HOME/bin/java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR3_20160915_0912_B318796 > JIT - tr.r14.java.green_20160818_122998 > GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS > J9CL - 20160915_318796) > JCL - 20160914_01 based on Oracle jdk8u101-b13 > > mvn clean test -Dtest=KeyStoreCredentialStoreTest > {code} > Expected: KeyStoreCredentialStoreTest should pass > Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws > {code} > java.lang.ClassNotFoundException: javax.crypto.JceSecurity > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:278) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89) > ... > {code} > because {{javax.crypto.JceSecurity}} does not exist in IBM JRE. > It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK. > But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception: > {code} > org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available > at java.security.KeyStore.getEntry(KeyStore.java:1532) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462) > ... 10 more > Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available > ... 12 more > {code} > [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9610) Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution

by Serg Pol (JIRA)

[ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.... ] Serg Pol edited comment on WFLY-9610 at 1/10/18 10:29 AM: ---------------------------------------------------------- thanks "So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?" - i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs. "What part of the application code is executed that you don't expect them to be executed?" - i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING) than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown. was (Author: serg_732173): thanks "So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?" * i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs. "What part of the application code is executed that you don't expect them to be executed?" * i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING) than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown. > Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9610 > URL: https://issues.jboss.org/browse/WFLY-9610 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 9.0.1.Final > Environment: Cluster, standalone-full-ha > Reporter: Serg Pol > Assignee: Cheng Fang > > Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). > There are no any error nessages. > BatchJob is not started in this case according Log. > Any idea? Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9610) Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution

by Serg Pol (JIRA)

[ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.... ] Serg Pol edited comment on WFLY-9610 at 1/10/18 10:28 AM: ---------------------------------------------------------- thanks "So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?" * i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs. "What part of the application code is executed that you don't expect them to be executed?" * i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING) than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown. was (Author: serg_732173): thanks "So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?" * i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs. "What part of the application code is executed that you don't expect them to be executed?" * i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING) than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown. > Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9610 > URL: https://issues.jboss.org/browse/WFLY-9610 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 9.0.1.Final > Environment: Cluster, standalone-full-ha > Reporter: Serg Pol > Assignee: Cheng Fang > > Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). > There are no any error nessages. > BatchJob is not started in this case according Log. > Any idea? Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9610) Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution

by Serg Pol (JIRA)

[ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.... ] Serg Pol commented on WFLY-9610: -------------------------------- thanks "So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?" * i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs. "What part of the application code is executed that you don't expect them to be executed?" * i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING) than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown. > Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9610 > URL: https://issues.jboss.org/browse/WFLY-9610 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 9.0.1.Final > Environment: Cluster, standalone-full-ha > Reporter: Serg Pol > Assignee: Cheng Fang > > Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). > There are no any error nessages. > BatchJob is not started in this case according Log. > Any idea? Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9610) Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.... ] Cheng Fang commented on WFLY-9610: ---------------------------------- So the batch status transition is: STARTING -> STOPPING -> STOPPED If the stop request is issued early enough (while the job execution is still waiting for available threads), the job execution batch status will be set to STOPPING, and from STOPPING the only outcome is STOPPED. So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"? What part of the application code is executed that you don't expect them to be executed? > Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9610 > URL: https://issues.jboss.org/browse/WFLY-9610 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 9.0.1.Final > Environment: Cluster, standalone-full-ha > Reporter: Serg Pol > Assignee: Cheng Fang > > Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). > There are no any error nessages. > BatchJob is not started in this case according Log. > Any idea? Thanks -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1485) HTTP DIGEST requires cnonce to be base64

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1485?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1485. --------------------------- Resolution: Rejected Sorry, my fault, mismatched nonce and cnonce, it is required only for server nonce, which is correct. > HTTP DIGEST requires cnonce to be base64 > ---------------------------------------- > > Key: ELY-1485 > URL: https://issues.jboss.org/browse/ELY-1485 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.2.0.Beta11 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: digest > > NonceManager of HTTP DIGEST mechanism requires nonce to base64 encoded value, otherwise it fails on DecodeException. > In RFC there is no requirement for client to use base64 value as cnonce. There is only recommendation for server nonce: > {panel} > nonce > A server-specified data string which MUST be different each time a > digest-challenge is sent as part of initial authentication. It is > *recommended* that this string be base64 or hexadecimal data. > {panel} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1485) HTTP DIGEST requires cnonce to be base64

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1485?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1485: ---------------------------- Labels: digest (was: ) > HTTP DIGEST requires cnonce to be base64 > ---------------------------------------- > > Key: ELY-1485 > URL: https://issues.jboss.org/browse/ELY-1485 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.2.0.Beta11 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: digest > > NonceManager of HTTP DIGEST mechanism requires nonce to base64 encoded value, otherwise it fails on DecodeException. > In RFC there is no requirement for client to use base64 value as cnonce. There is only recommendation for server nonce: > {panel} > nonce > A server-specified data string which MUST be different each time a > digest-challenge is sent as part of initial authentication. It is > *recommended* that this string be base64 or hexadecimal data. > {panel} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2018