[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations
by Xavier Mourgues (JIRA)
[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ]
Xavier Mourgues edited comment on JBEE-171 at 9/1/17 12:17 PM:
---------------------------------------------------------------
Hello,
I'm, currently facing this issue.
Is there any workaround available ?
Cheers
was (Author: xqvier):
Hello,
I', currently facing this issue.
Is there any workaround available ?
Cheers
> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
> Key: JBEE-171
> URL: https://issues.jboss.org/browse/JBEE-171
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jsf-api
> Reporter: Markus Pollak
> Assignee: Dmitrii Tikhomirov
>
> Hello,
> I’ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems…
> Best Regards,
> Markus Pollak
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations
by Xavier Mourgues (JIRA)
[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ]
Xavier Mourgues commented on JBEE-171:
--------------------------------------
Hello,
I', currently facing this issue.
Is there any workaround available ?
Cheers
> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
> Key: JBEE-171
> URL: https://issues.jboss.org/browse/JBEE-171
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jsf-api
> Reporter: Markus Pollak
> Assignee: Dmitrii Tikhomirov
>
> Hello,
> I’ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems…
> Best Regards,
> Markus Pollak
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3227) Legacy slaves can't understand new enum version values
by Ken Wills (JIRA)
Ken Wills created WFCORE-3227:
---------------------------------
Summary: Legacy slaves can't understand new enum version values
Key: WFCORE-3227
URL: https://issues.jboss.org/browse/WFCORE-3227
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Priority: Blocker
[Host Controller] 10:53:50,342 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("add") failed - address: ([("host-exclude" => "EAP70")]) - failure description: "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"
[Host Controller] 10:53:50,366 ERROR [org.jboss.as.host.controller] (Host Controller Service Threads - 2) WFLYHC0143: Failed to apply domain-wide configuration from master host controller. Operation outcome: failed. Failure description {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"}}
[Host Controller] 10:53:50,448 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://192.168.122.71:9999 -- 1-$-
[Host Controller] 10:53:50,449 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
[Host Controller] 10:53:50,451 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3226) Legacy slaves can't understand new enum version values
by Ken Wills (JIRA)
Ken Wills created WFCORE-3226:
---------------------------------
Summary: Legacy slaves can't understand new enum version values
Key: WFCORE-3226
URL: https://issues.jboss.org/browse/WFCORE-3226
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Priority: Blocker
Attachments: domain.xml, host-slave.xml
[Host Controller] 10:53:50,342 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("add") failed - address: ([("host-exclude" => "EAP70")]) - failure description: "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"
[Host Controller] 10:53:50,366 ERROR [org.jboss.as.host.controller] (Host Controller Service Threads - 2) WFLYHC0143: Failed to apply domain-wide configuration from master host controller. Operation outcome: failed. Failure description {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"}}
[Host Controller] 10:53:50,448 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://192.168.122.71:9999 -- 1-$-
[Host Controller] 10:53:50,449 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
[Host Controller] 10:53:50,451 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3225) CLI, keep full stack trace
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-3225:
--------------------------------------------
Summary: CLI, keep full stack trace
Key: WFCORE-3225
URL: https://issues.jboss.org/browse/WFCORE-3225
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Priority: Minor
CLI is re-throwing the exception thrown in the async task. The calling stack is lost. It has no impact for CLI users but is annoying when using CLI programmatically.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-386:
---------------------------------
I think it would probably be a good idea to support both names.
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-386:
--------------------------------
Problem in *DHE-DSS-CBC-SHA* is there are two OpenSSL names for one standard name:
{code}
TLS_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,...
TLS_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-CBC-SHA,...
{code}
We would need to implement aliases for OSSL names (currectly we have aliases only for stdNames), or at least to allow more entries for one stdName (which currently causes warning and ignore second definition).
[~dmlloyd] Do we want to support both OSSL names for TLS_DHE_DSS_WITH_DES_CBC_SHA? It looks like most of projects supports only one of this names.
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-8954:
------------------------------------
Rather than lookup the "java:comp/TransactionSynchronizationRegistry", which requires "java:comp" to be setup, we might be able to instead use JNDI "java:jboss/TransactionSynchronizationRegistry".
Your approach to the change looks very good! :-)
When you create a WildFly pull request for this change, please update this jira. If you have any questions about submitting the pull request, please refer to the [https://developer.jboss.org/wiki/HackingOnWildFly]. Or you can ask questions here as well.
Thanks,
Scott
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos edited comment on WFLY-8954 at 9/1/17 9:08 AM:
---------------------------------------------------------------------
No.
The issue not solved!
I have a system test where this issue can still be reproduced.
I can no longer reproduce it using the sample application, but we do have a scenario in a system test where after refreshing the entity we get different data than what we have in the server session cache.
Not good...
Actually, good.
The fix is most likely working perfectly. The issue I am looking at is a incorrectly named event class, that was leading for my dirty "state" check to be run against a the wrong entity field.
However, the refresh action is being redundant. That is a very good indication.
I believe my impression above is nothing but a false negative.
We are still in the clear for now...
Changes are so far looking good.
I have taken the dirty code that was specific to wildfly onobsever bug from our code, and I will see if the CI system tests are fine all accross.
NOTE:
- I will be opening a new wildfly JIRA related to the unregister connection problem mentioned on a wildfly thread.
{panel}
java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@40a9ad99
{panel}
This issue is not addressed by this fix.
Thanks.
was (Author: nuno.godinhomatos):
No.
The issue not solved!
I have a system test where this issue can still be reproduced.
I can no longer reproduce it using the sample application, but we do have a scenario in a system test where after refreshing the entity we get different data than what we have in the server session cache.
Not good...
Actually, good.
The fix is most likely working perfectly. The issue I am looking at is a incorrectly named event class, that was leading for my dirty "state" check to be run against a the wrong entity field.
However, the refresh action is being redundant. That is a very good indication.
I believe my impression above is nothing but a false negative.
We are still in the clear for now...
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina reassigned ELY-386:
------------------------------
Assignee: Jan Kalina
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months