[JBoss JIRA] (ELY-1443) Jdbc-realm with scram mapper and empty password
by Martin Mazanek (JIRA)
[ https://issues.jboss.org/browse/ELY-1443?page=com.atlassian.jira.plugin.s... ]
Martin Mazanek reassigned ELY-1443:
-----------------------------------
Assignee: Martin Mazanek
> Jdbc-realm with scram mapper and empty password
> -----------------------------------------------
>
> Key: ELY-1443
> URL: https://issues.jboss.org/browse/ELY-1443
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Passwords
> Affects Versions: 1.2.0.Beta9
> Reporter: Martin Choma
> Assignee: Martin Mazanek
>
> This is follow up on ELY-1435, but in this case trying scram hash.
> In DB there is
> {noformat}
> Salt: c2FsdA==
> Password: YywoEuRtRgQQK6dhjp1tfS+BKPYma0oDJk0qBGC33LM=
> Salt: 1000
> {noformat}
> I get these values by
> {code:java|name=ScramDigestPasswordTest.java}
> digest = ScramDigestPasswordImpl.scramDigest(ALGORITHM_SCRAM_SHA_256, "password".getBytes(StandardCharsets.UTF_8), "salt".getBytes(StandardCharsets.UTF_8), 1000);
> assertEquals("632c2812e46d4604102ba7618e9d6d7d2f8128f6266b4a03264d2a0460b7dcb3", ByteIterator.ofBytes(digest).hexEncode().drainToString());
> spec = new IteratedSaltedHashPasswordSpec(digest, "salt".getBytes(StandardCharsets.UTF_8), 1000);
> impl = new ScramDigestPasswordImpl(ALGORITHM_SCRAM_SHA_256, spec);
> assertTrue(impl.verify("password".toCharArray()));
> assertFalse(impl.verify("bad".toCharArray()));
> Encoder encoder = Base64.getEncoder();
> String elytronSalt = encoder.encodeToString( impl.getSalt() );
> String elytronHash = encoder.encodeToString( impl.getDigest() );
> int itertationCount = impl.getIterationCount();
> {code}
> When user provides empty password "", there is error.
> {noformat}
> 17:05:40,723 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
> 17:05:40,723 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
> 17:05:40,727 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
> 17:05:40,813 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
> 17:05:40,817 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
> 17:05:40,865 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /elytron-app/protected/printRoles: java.lang.IllegalArgumentException: Empty key
> at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:96)
> at org.wildfly.security.password.impl.ScramDigestPasswordImpl.getMacInstance(ScramDigestPasswordImpl.java:281)
> at org.wildfly.security.password.impl.ScramDigestPasswordImpl.scramDigest(ScramDigestPasswordImpl.java:240)
> at org.wildfly.security.password.impl.ScramDigestPasswordImpl.verify(ScramDigestPasswordImpl.java:195)
> at org.wildfly.security.password.impl.PasswordFactorySpiImpl.engineVerify(PasswordFactorySpiImpl.java:755)
> at org.wildfly.security.password.PasswordFactory.verify(PasswordFactory.java:209)
> at org.wildfly.security.credential.PasswordCredential.verify(PasswordCredential.java:116)
> at org.wildfly.security.credential.Credential.verify(Credential.java:79)
> at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.verifyEvidence(JdbcSecurityRealm.java:199)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1052)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:76)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4018) Remove alias and read-aliases in a batch causes blocking behavior
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4018?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFCORE-4018:
---------------------------------------
[~honza889], I see the {{ReadAliasesHandler}} is calling this method ([GitHub|https://github.com/wildfly/wildfly-core/blob/master/elytron/src/ma...]):
{code:java}
static KeyStore getKeyStore(OperationContext context) throws OperationFailedException {
ServiceRegistry serviceRegistry = context.getServiceRegistry(true);
…
{code}
{{read-aliases}} is not supposed to be a modifying operation, is it? I.e. it should call {{getServiceRegistry(false)}}. Which if it does this particular issue is solved though it doesn't resolve the syncing problem.
> Remove alias and read-aliases in a batch causes blocking behavior
> -----------------------------------------------------------------
>
> Key: WFCORE-4018
> URL: https://issues.jboss.org/browse/WFCORE-4018
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Michal Petrov
>
> Calling :remove-alias and :read-aliases on key-store resource in a composite operation makes the resource blocked.
> Generate two self signed certificates on a key-store resource and store it.
> {code}
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:generate-key-pair(alias=foobar,distinguished-name="cn=claudio,c=BR")
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:generate-key-pair(alias=foobar2,distinguished-name="cn=claudio2,c=BR")
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:store()
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:read-aliases
> {
> "outcome" => "success",
> "result" => [
> "foobar2",
> "foobar"
> ]
> }
> {code}
> {code}
> batch
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:remove-alias(alias=foobar)
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:read-aliases
> run-batch
> {code}
> The above just blocks the prompt.
> Then the blocking operation is show as:
> {code}
> /host=master/core-service=management/service=management-operations:read-resource(include-runtime,recursive)
> {
> "outcome" => "success",
> "result" => {"active-operation" => {
> "352328021" => {
> "access-mechanism" => "NATIVE",
> "address" => [
> ("host" => "master"),
> ("core-service" => "management"),
> ("service" => "management-operations")
> ],
> "caller-thread" => "management-handler-thread - 1",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => undefined,
> "exclusive-running-time" => -1L,
> "execution-status" => "executing",
> "operation" => "read-resource",
> "running-time" => 10032404L
> },
> "-1467399640" => {
> "access-mechanism" => "NATIVE",
> "address" => [],
> "caller-thread" => "management-handler-thread - 2",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => undefined,
> "exclusive-running-time" => -1L,
> "execution-status" => "executing",
> "operation" => "composite",
> "running-time" => 260150849919L
> }
> }}
> }
> {code}
> After timeout there is the following message on CLI prompt
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /host=master/server=server-three/subsystem=elytron/key-store=keysto1:read-aliases
> Failure: WFLYCTL0409: Execution of operation 'read-aliases' on remote process at address '[
> ("host" => "master"),
> ("server" => "server-three")
> ]' timed out after 305000 ms while awaiting initial response; remote process has been notified to terminate operation
> {code}
> To fix the problem in HAL I will run it as individual commands.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ELY-1535) CipherSuiteSelector does not know about CHACHA20_POLY1305
by Martin Mazanek (JIRA)
[ https://issues.jboss.org/browse/ELY-1535?page=com.atlassian.jira.plugin.s... ]
Martin Mazanek reassigned ELY-1535:
-----------------------------------
Assignee: Martin Mazanek
> CipherSuiteSelector does not know about CHACHA20_POLY1305
> ---------------------------------------------------------
>
> Key: ELY-1535
> URL: https://issues.jboss.org/browse/ELY-1535
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Mike Yoder
> Assignee: Martin Mazanek
>
> I was trying to be a good person and implement the Mozilla "Modern" cipher suite described here:
> https://wiki.mozilla.org/Security/Server_Side_TLS
> I'm doing this in a keycloak server. The config line there looks like
> {noformat}
> <https-listener security-realm="ApplicationRealm"
> enabled-protocols="SSLv2Hello,TLSv1.2"
> enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
> name="default"
> socket-binding="httpish"
> enable-http2="true"
> proxy-address-forwarding="true"
> />
> {noformat}
> But I got this:
> {noformat}
> 13:20:46,574 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in serv
> ice org.wildfly.undertow.listener.default: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: ELY05016: Unrecognized token "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256" in mechanism selection string "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:423)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:120)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> {noformat}
> With a little digging it appears that CipherSuiteSelector doesn't know what CHACHA20 or POLY1305 are. See:
> https://github.com/wildfly-security/wildfly-elytron/blame/master/src/main...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4089) Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4089?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-4089:
-------------------------------
Fix Version/s: 8.0.0.Alpha
(was: 7.0.0.Alpha1)
> Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
> -----------------------------------------------------------------------
>
> Key: WFCORE-4089
> URL: https://issues.jboss.org/browse/WFCORE-4089
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Kabir Khan
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 8.0.0.Alpha
>
>
> I suggest adding a ModelTestControllerVersion.EAP_7_2_0_TMP which is deprecated and pulls in the WF14 artifacts. Once EAP 7.2.0 is out, we need to add EAP_7_2_0 proper, and go through and adjust all the tests using the tmp version. I think this is ok, as there are some more advances subsystem tests which specify additional maven artifacts. Those maven artifacts will need to be updated to use the proper EAP 7.2.0 artifacts once it is released, and having to do this replacement will serve as a reminder.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4089) Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4089?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-4089:
-------------------------------
Description: Once EAP 7.2.0 is out, remove ModelTestControllerVersion.EAP_7_2_0_TMP and add EAP_7_2_0 proper, and go through and adjust all the tests using the tmp version. I think this is ok, as there are some more advances subsystem tests which specify additional maven artifacts. Those maven artifacts will need to be updated to use the proper EAP 7.2.0 artifacts once it is released, and having to do this replacement will serve as a reminder. (was: I suggest adding a ModelTestControllerVersion.EAP_7_2_0_TMP which is deprecated and pulls in the WF14 artifacts. Once EAP 7.2.0 is out, we need to add EAP_7_2_0 proper, and go through and adjust all the tests using the tmp version. I think this is ok, as there are some more advances subsystem tests which specify additional maven artifacts. Those maven artifacts will need to be updated to use the proper EAP 7.2.0 artifacts once it is released, and having to do this replacement will serve as a reminder.)
> Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
> -----------------------------------------------------------------------
>
> Key: WFCORE-4089
> URL: https://issues.jboss.org/browse/WFCORE-4089
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Kabir Khan
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 8.0.0.Alpha
>
>
> Once EAP 7.2.0 is out, remove ModelTestControllerVersion.EAP_7_2_0_TMP and add EAP_7_2_0 proper, and go through and adjust all the tests using the tmp version. I think this is ok, as there are some more advances subsystem tests which specify additional maven artifacts. Those maven artifacts will need to be updated to use the proper EAP 7.2.0 artifacts once it is released, and having to do this replacement will serve as a reminder.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4089) Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4089?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-4089:
-------------------------------
Priority: Blocker (was: Major)
> Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
> -----------------------------------------------------------------------
>
> Key: WFCORE-4089
> URL: https://issues.jboss.org/browse/WFCORE-4089
> Project: WildFly Core
> Issue Type: Task
> Components: Management
> Reporter: Kabir Khan
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 7.0.0.Alpha1
>
>
> I suggest adding a ModelTestControllerVersion.EAP_7_2_0_TMP which is deprecated and pulls in the WF14 artifacts. Once EAP 7.2.0 is out, we need to add EAP_7_2_0 proper, and go through and adjust all the tests using the tmp version. I think this is ok, as there are some more advances subsystem tests which specify additional maven artifacts. Those maven artifacts will need to be updated to use the proper EAP 7.2.0 artifacts once it is released, and having to do this replacement will serve as a reminder.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4089) Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-4089:
----------------------------------
Summary: Update subsystem and core-model tests to use EAP 7.2.0 rather than WF14
Key: WFCORE-4089
URL: https://issues.jboss.org/browse/WFCORE-4089
Project: WildFly Core
Issue Type: Task
Components: Management
Reporter: Kabir Khan
Assignee: Jeff Mesnil
Fix For: 7.0.0.Alpha1
I suggest adding a ModelTestControllerVersion.EAP_7_2_0_TMP which is deprecated and pulls in the WF14 artifacts. Once EAP 7.2.0 is out, we need to add EAP_7_2_0 proper, and go through and adjust all the tests using the tmp version. I think this is ok, as there are some more advances subsystem tests which specify additional maven artifacts. Those maven artifacts will need to be updated to use the proper EAP 7.2.0 artifacts once it is released, and having to do this replacement will serve as a reminder.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months