[jira] [Commented] (CXF-9033) getSignatureAlgorithm ignores alg value set within JWS header
[ https://issues.apache.org/jira/browse/CXF-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871244#comment-17871244 ] Colm O hEigeartaigh commented on CXF-9033: -- [~jan4talend] See [https://nathantypanski.com/blog/2021-12-24-jws-nightmare.html] there is another attack (Attacker-controlled algorithms). Also for SOAP we have WS-SecurityPolicy to enforce signature algorithms. > getSignatureAlgorithm ignores alg value set within JWS header > - > > Key: CXF-9033 > URL: https://issues.apache.org/jira/browse/CXF-9033 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Affects Versions: 3.5.8, 3.6.3, 4.0.4 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Major > > The `getSignatureAlgorithm` method from the > [JwsUtils|https://github.com/apache/cxf/blob/cxf-3.6.3/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsUtils.java] > ignore any value set within the "alg" JWS header, instead the code looks for > a static JAX-RS property (rs.security.signature.algorithm) or tries to detect > the algorithm based on the selected alias in a keystore file. This makes it > more complicated to configure a CXF provider and limits the token validation > to a single specified algorythm. Using the header value instead would avoid > such additional configuration properties and make the solution more dynamic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9033) getSignatureAlgorithm ignores alg value set within JWS header
[ https://issues.apache.org/jira/browse/CXF-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867729#comment-17867729 ] Colm O hEigeartaigh commented on CXF-9033: -- [~jan4talend] It's by design, otherwise you hand control of the signature verification process to the message sender (e.g. set ALG=NONE). > getSignatureAlgorithm ignores alg value set within JWS header > - > > Key: CXF-9033 > URL: https://issues.apache.org/jira/browse/CXF-9033 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Affects Versions: 3.5.8, 3.6.3, 4.0.4 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Major > > The `getSignatureAlgorithm` method from the > [JwsUtils|https://github.com/apache/cxf/blob/cxf-3.6.3/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsUtils.java] > ignore any value set within the "alg" JWS header, instead the code looks for > a static JAX-RS property (rs.security.signature.algorithm) or tries to detect > the algorithm based on the selected alias in a keystore file. This makes it > more complicated to configure a CXF provider and limits the token validation > to a single specified algorythm. Using the header value instead would avoid > such additional configuration properties and make the solution more dynamic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-9009) Async operations fail in concurrent calls
[ https://issues.apache.org/jira/browse/CXF-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866322#comment-17866322 ] Colm O hEigeartaigh commented on CXF-9009: -- [~juliojgd] It's under vote at the moment, expect it to appear in Maven Central by the end of the week. > Async operations fail in concurrent calls > - > > Key: CXF-9009 > URL: https://issues.apache.org/jira/browse/CXF-9009 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.5.8, 3.6.3, 4.0.4 >Reporter: Julio J. Gomez Diaz >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.9, 4.1.0, 4.0.5, 3.6.4 > > Attachments: spring-soap.zip > > > An exception occurs when a SOAP client is used concurrently in async > operations, the exception is as follows: > > > {code:java} > org.apache.cxf.interceptor.Fault: Could not send Message. > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67) > ~[cxf-core-4.0.4.jar:4.0.4] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > ~[cxf-core-4.0.4.jar:4.0.4] > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) > ~[cxf-core-4.0.4.jar:4.0.4] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:434) > ~[cxf-core-4.0.4.jar:4.0.4] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:412) > ~[cxf-core-4.0.4.jar:4.0.4] > at > org.apache.cxf.jaxws.JaxWsClientProxy.invokeAsync(JaxWsClientProxy.java:326) > ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4] > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) > ~[cxf-rt-frontend-jaxws-4.0.4.jar:4.0.4] > at jdk.proxy2/jdk.proxy2.$Proxy95.countAsync(Unknown Source) ~[na:na] > at > com.example.demo.rest.RestController.lambda$async$1(RestController.java:25) > ~[classes/:na] > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) > ~[na:na] > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > ~[na:na] > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > ~[na:na] > at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na] > Caused by: io.netty.channel.StacklessClosedChannelException: null > at > io.netty.channel.AbstractChannel$AbstractUnsafe.ensureOpen(ChannelPromise)(Unknown > Source) ~[netty-transport-4.1.109.Final.jar:4.1.109.Final]{code} > > I created an reproducer application (find attached "spring-soap.zip") that > acts as client and server, and this publishes the following operations: > * [http://localhost:8080/async] -> it uses a soap client to call > concurrently using an async operation (this {*}fails with the exception > previously described{*}) > * [http://localhost:8080/sync] -> it uses a soap client to call concurrently > using an ordinary operation (ends without errors) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8999) KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8999. -- Resolution: Fixed > KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java > - > > Key: CXF-8999 > URL: https://issues.apache.org/jira/browse/CXF-8999 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.9, 4.0.5, 3.6.4 > > > KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java. > The test case fails on ClassNotFound com.ibm.security.jgss.InquireType - this > is thrown due to wss4j-ws-security-common having a hard coded check for IBM > Java to use the above mentioned class. > {{KerberosClientExceptionAction.class:}} > {{`}} > {{{}try{}}}{{{}{ {}}} > {{ Class inquireType = Class.forName(IS_IBM_VENDOR ? > "com.ibm.security.jgss.InquireType" : "com.sun.security.jgss.InquireType"); }} > {{ Class extendedGSSContext = Class.forName(IS_IBM_VENDOR ? > "com.ibm.security.jgss.ExtendedGSSContext" : > "com.sun.security.jgss.ExtendedGSSContext"); }} > {{ Method inquireSecContext = > extendedGSSContext.getMethod("inquireSecContext", inquireType); }} > {{ Key key = (Key)inquireSecContext.invoke(secContext, > Enum.valueOf(inquireType, "KRB5_GET_SESSION_KEY")); > krbCtx.setSecretKey(key); }} > {{ return krbCtx; }} > {{} }}{{{}catch (NoSuchMethodException | IllegalAccessException | > InvocationTargetException | ClassNotFoundException var13){}}}{{{}{ {}}} > {{ throw new WSSecurityException(ErrorCode.FAILURE, var13, > "kerberosServiceTicketError"); }} > {{}}} > ` > Most of the test cases in KerberosTokenTest are set to avoid running when on > IBM, I believe this test case should also be set to not run. A future > improvement would be to update wss4j-ws-security-common to be IBM Semeru > friendly, then update CXF accordingly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8999) KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8999: - Fix Version/s: 3.5.9 3.6.4 > KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java > - > > Key: CXF-8999 > URL: https://issues.apache.org/jira/browse/CXF-8999 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Priority: Major > Fix For: 3.5.9, 4.0.5, 3.6.4 > > > KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java. > The test case fails on ClassNotFound com.ibm.security.jgss.InquireType - this > is thrown due to wss4j-ws-security-common having a hard coded check for IBM > Java to use the above mentioned class. > {{KerberosClientExceptionAction.class:}} > {{`}} > {{{}try{}}}{{{}{ {}}} > {{ Class inquireType = Class.forName(IS_IBM_VENDOR ? > "com.ibm.security.jgss.InquireType" : "com.sun.security.jgss.InquireType"); }} > {{ Class extendedGSSContext = Class.forName(IS_IBM_VENDOR ? > "com.ibm.security.jgss.ExtendedGSSContext" : > "com.sun.security.jgss.ExtendedGSSContext"); }} > {{ Method inquireSecContext = > extendedGSSContext.getMethod("inquireSecContext", inquireType); }} > {{ Key key = (Key)inquireSecContext.invoke(secContext, > Enum.valueOf(inquireType, "KRB5_GET_SESSION_KEY")); > krbCtx.setSecretKey(key); }} > {{ return krbCtx; }} > {{} }}{{{}catch (NoSuchMethodException | IllegalAccessException | > InvocationTargetException | ClassNotFoundException var13){}}}{{{}{ {}}} > {{ throw new WSSecurityException(ErrorCode.FAILURE, var13, > "kerberosServiceTicketError"); }} > {{}}} > ` > Most of the test cases in KerberosTokenTest are set to avoid running when on > IBM, I believe this test case should also be set to not run. A future > improvement would be to update wss4j-ws-security-common to be IBM Semeru > friendly, then update CXF accordingly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8999) KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java
[ https://issues.apache.org/jira/browse/CXF-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8999: Assignee: Colm O hEigeartaigh > KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java > - > > Key: CXF-8999 > URL: https://issues.apache.org/jira/browse/CXF-8999 > Project: CXF > Issue Type: Test >Affects Versions: 4.0.4 >Reporter: Jamie Mark Goodyear >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.9, 4.0.5, 3.6.4 > > > KerberosTokenTest testKerberosViaCustomTokenAction should not run on IBM Java. > The test case fails on ClassNotFound com.ibm.security.jgss.InquireType - this > is thrown due to wss4j-ws-security-common having a hard coded check for IBM > Java to use the above mentioned class. > {{KerberosClientExceptionAction.class:}} > {{`}} > {{{}try{}}}{{{}{ {}}} > {{ Class inquireType = Class.forName(IS_IBM_VENDOR ? > "com.ibm.security.jgss.InquireType" : "com.sun.security.jgss.InquireType"); }} > {{ Class extendedGSSContext = Class.forName(IS_IBM_VENDOR ? > "com.ibm.security.jgss.ExtendedGSSContext" : > "com.sun.security.jgss.ExtendedGSSContext"); }} > {{ Method inquireSecContext = > extendedGSSContext.getMethod("inquireSecContext", inquireType); }} > {{ Key key = (Key)inquireSecContext.invoke(secContext, > Enum.valueOf(inquireType, "KRB5_GET_SESSION_KEY")); > krbCtx.setSecretKey(key); }} > {{ return krbCtx; }} > {{} }}{{{}catch (NoSuchMethodException | IllegalAccessException | > InvocationTargetException | ClassNotFoundException var13){}}}{{{}{ {}}} > {{ throw new WSSecurityException(ErrorCode.FAILURE, var13, > "kerberosServiceTicketError"); }} > {{}}} > ` > Most of the test cases in KerberosTokenTest are set to avoid running when on > IBM, I believe this test case should also be set to not run. A future > improvement would be to update wss4j-ws-security-common to be IBM Semeru > friendly, then update CXF accordingly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8995) OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
[ https://issues.apache.org/jira/browse/CXF-8995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834254#comment-17834254 ] Colm O hEigeartaigh commented on CXF-8995: -- Can you give a test-case? > OpcodesProxy java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds > for length 7 > - > > Key: CXF-8995 > URL: https://issues.apache.org/jira/browse/CXF-8995 > Project: CXF > Issue Type: Bug >Affects Versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3 >Reporter: Florian Wermelskirchen >Priority: Major > > After upgrading our software to apache camel 3.22.1 and cxf 3.6.2 we get this > Error running our Tests. > {code:java} > 2024-04-02 14:44:01,698 | ERROR | Test worker | > org.apache.camel.impl.engine.AbstractCamelContext | Error starting > CamelContext (camel-1) due to exception thrown: Index 7 out of bounds for > length 7 > java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7 > at org.apache.cxf.common.util.OpcodesProxy.(OpcodesProxy.java:37) > at > org.apache.cxf.common.util.ASMHelperImpl.getOpCodes(ASMHelperImpl.java:105) > at > org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:200) > at > org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:122) > at > org.apache.cxf.jaxws.spi.WrapperClassCreatorProxyService.generate(WrapperClassCreatorProxyService.java:40) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:670) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.getExtraClass(JaxWsServiceFactoryBean.java:642) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:463) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211) > at > org.apache.camel.component.cxf.jaxws.CxfConsumer.createServer(CxfConsumer.java:75) > at > org.apache.camel.component.cxf.jaxws.CxfConsumer.doStart(CxfConsumer.java:107) > at > org.apache.camel.support.service.BaseService.start(BaseService.java:119) > at > org.apache.camel.support.service.ServiceHelper.startService(ServiceHelper.java:113) > at > org.apache.camel.impl.engine.AbstractCamelContext.startService(AbstractCamelContext.java:3760) > at > org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRouteConsumers(InternalRouteStartupManager.java:401) > at > org.apache.camel.impl.engine.InternalRouteStartupManager.doStartRouteConsumers(InternalRouteStartupManager.java:319) > at > org.apache.camel.impl.engine.InternalRouteStartupManager.safelyStartRouteServices(InternalRouteStartupManager.java:213) > at > org.apache.camel.impl.engine.InternalRouteStartupManager.doStartOrResumeRoutes(InternalRouteStartupManager.java:147) > at > org.apache.camel.impl.engine.AbstractCamelContext.doStartCamel(AbstractCamelContext.java:3445) > at > org.apache.camel.impl.engine.AbstractCamelContext.doStartContext(AbstractCamelContext.java:3114) > at > org.apache.camel.impl.engine.AbstractCamelContext.doStart(AbstractCamelContext.java:3069) > at > org.apache.camel.spring.boot.SpringBootCamelContext.doStart(SpringBootCamelContext.java:43) > at > org.apache.camel.support.service.BaseService.start(BaseService.java:119) > at > org.apache.camel.impl.engine.AbstractCamelContext.start(AbstractCamelContext.java:2718) > at > org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:262) > at > org.apache.camel.spring.SpringCamelContext.start(SpringCamelContext.java:119) > at > org.apache.camel.test.spring.junit5.CamelAnnotationsHandler$8.execute(CamelAnnotationsHandler.java:407) > at > org.apache.camel.test.spring.junit5.CamelSpringTestHelper.doToSpringCamelContexts(CamelSpringTestHelper.java:108) > at > org.apache.camel.test.spring.junit5.CamelAnnotationsHandler.handleCamelContextStartup(CamelAnnotationsHandler.java:400) > at
[jira] [Closed] (FEDIZ-256) Tomcat authenticationSessionTimeout
[ https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-256. - > Tomcat authenticationSessionTimeout > --- > > Key: FEDIZ-256 > URL: https://issues.apache.org/jira/browse/FEDIZ-256 > Project: CXF-Fediz > Issue Type: Bug > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Tomas Milian >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 1.6.2 > > > Hello, > I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue. > Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute > (authenticationSessionTimeout) that breaks Fediz authentication process. > {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change > introduced in Tomcat 9.0.74 replaces the original session timeout with the > authenticationSessionTimeout default value (120 seconds).{color} > {code:java} > if (session instanceof HttpSession && ((HttpSession) > session).isNew()) { > int originalMaxInactiveInterval = > session.getMaxInactiveInterval(); > if (originalMaxInactiveInterval > > getAuthenticationSessionTimeout()) { > > saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); > > session.setMaxInactiveInterval(getAuthenticationSessionTimeout()); > } > } {code} > {color:#172b4d}Once the Fediz authentication is resumed, the original session > maxInactiveInterval is not restored, so authenticated session always ends up > with a 120 second maxInactiveInterval{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FEDIZ-257) Apache CXF Fediz Tomcat Plugin ver 1.6.1 does not work with Jakarta
[ https://issues.apache.org/jira/browse/FEDIZ-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824509#comment-17824509 ] Colm O hEigeartaigh commented on FEDIZ-257: --- At this point I have no plans to update Fediz with CXF 4.0.0 / Jakarta, unless someone wants to contribute it. > Apache CXF Fediz Tomcat Plugin ver 1.6.1 does not work with Jakarta > --- > > Key: FEDIZ-257 > URL: https://issues.apache.org/jira/browse/FEDIZ-257 > Project: CXF-Fediz > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Mark >Priority: Major > Fix For: 1.6.1 > > > The following version of the fediz tomcat plugin was compiled with JDK 1.6 > and uses > https://cxf.apache.org/fediz-downloads.html > https://downloads.apache.org/cxf/fediz/1.6.1/ > If using version 1.6.1 with TomEE https://tomee.apache.org/download.html > I see errors encountering, java.lang.NoClassDefFoundError: > javax/xml/bind/JAXBException, that indicates the Java JAXB (Java Architecture > for XML Binding) API is not available in the runtime environment. This issue > is commonly encountered when running applications on Java versions 9 and > later, as JAXB was removed from the Java SE platform starting with Java 11. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8691) Logging Feature - Sensitive element with arrays
[ https://issues.apache.org/jira/browse/CXF-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8691: - Fix Version/s: 3.5.9 3.6.4 (was: 3.5.8) (was: 3.6.3) > Logging Feature - Sensitive element with arrays > --- > > Key: CXF-8691 > URL: https://issues.apache.org/jira/browse/CXF-8691 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.4.0, 3.5.1 >Reporter: Daniel >Assignee: Andriy Redko >Priority: Minor > Labels: Logging > Fix For: 3.5.9, 4.0.5, 3.6.4 > > > Hi, > I am trying to use the LoggingFeature within cxf-rt and hide sensitive > element names. > The code I use looks like the following: > > {code:java} > LoggingFeature loggingFeature = new LoggingFeature(); > loggingFeature.setLogBinary(false); > loggingFeature.setPrettyLogging(true); > loggingFeature.setLogMultipart(false); > loggingFeature.addSensitiveElementNames(new > HashSet<>(Arrays.asList("password"))); > {code} > Payload: > {code:java} > private final String shortName; > private final char[] password; > {code} > > Output: > > {code:java} > [services.MyWebservicePort.REQ_OUT] INFO - REQ_OUT > Address: http:// > HttpMethod: POST > Content-Type: application/json > ExchangeId: 560b73ae-e7e0-4687-9674-19ee72995a08 > Headers: {Accept=text/plain, Accept-Encoding=gzip;q=1.0, identity; q=0.5, > *;q=0, Content-Type=application/json} > Payload: > {"shortName":"UserName","password":["G","e","h","e","i","m","1","2","3","!"]} > {code} > As you can see, my password is not hidden in the output of the payload. It is > important to mention, that the field "password" in my code is declared as a > char-array. > However, if I add "shortName" to the sensetiveElementNames, everything works > as expected. The shortName is hidden (XXX), due to it beeing declared as a > String. > I looked at the source code an tracked the problem down to a regex. > "password" is not found, as the value is an array (MarkSensetiveHelper.java) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8950) HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
[ https://issues.apache.org/jira/browse/CXF-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8950: - Fix Version/s: 3.6.4 (was: 3.6.3) > HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT > - > > Key: CXF-8950 > URL: https://issues.apache.org/jira/browse/CXF-8950 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 4.0.3, 4.0.4 >Reporter: Sebastian Violet >Assignee: Daniel Kulp >Priority: Critical > Fix For: 4.0.5, 3.6.4 > > Attachments: CXF-HTTPClient-LargePayload.zip > > > When processing requests using the JAX RS client which used the new > HttpClient, there is the input stream is closed prematurely. > > [^CXF-HTTPClient-LargePayload.zip] , you will see that we are using > {*}Response{*}, because we are interested in getting response status as well > as the response headers. This fails with the following error: > {code:java} > Exception in thread "main" java.lang.RuntimeException: java.io.IOException: > closed > at LargeDataTester.main(LargeDataTester.java:89) > Caused by: java.io.IOException: closed > at > java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448) > at > java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508) > at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119) > at > org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422) > at > java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197) > at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333) > at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376) > at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219) > at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173) > at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189) > at java.base/java.io.Reader.read(Reader.java:265) > at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610) > at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589) > at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384) > at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153) > at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105) > at LargeDataTester.main(LargeDataTester.java:84) > Caused by: java.io.IOException: selector manager closed > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061) > at > java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552) > at > java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364) > {code} > > {color:#FF}*You can execute the code like so:*{color} > {code:java} > mvn compile exec:exec{code} > ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize > the object response payload automatically), and the last commit(Using > Response). > {code:java} > git diff HEAD^ HEAD {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7396: - Fix Version/s: 3.5.9 3.6.4 (was: 3.5.8) (was: 3.6.3) > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.9, 4.0.5, 3.6.4 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8629: - Fix Version/s: 3.5.9 3.6.4 (was: 3.5.8) (was: 3.6.3) > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.9, 4.0.5, 3.6.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8950) HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT
[ https://issues.apache.org/jira/browse/CXF-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8950: - Fix Version/s: 4.0.5 (was: 4.0.4) > HttpClient in CXF closing prematurely; 4.0.4-SNAPSHOT > - > > Key: CXF-8950 > URL: https://issues.apache.org/jira/browse/CXF-8950 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 4.0.3, 4.0.4 >Reporter: Sebastian Violet >Assignee: Daniel Kulp >Priority: Critical > Fix For: 3.6.3, 4.0.5 > > Attachments: CXF-HTTPClient-LargePayload.zip > > > When processing requests using the JAX RS client which used the new > HttpClient, there is the input stream is closed prematurely. > > [^CXF-HTTPClient-LargePayload.zip] , you will see that we are using > {*}Response{*}, because we are interested in getting response status as well > as the response headers. This fails with the following error: > {code:java} > Exception in thread "main" java.lang.RuntimeException: java.io.IOException: > closed > at LargeDataTester.main(LargeDataTester.java:89) > Caused by: java.io.IOException: closed > at > java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.current(ResponseSubscribers.java:448) > at > java.net.http/jdk.internal.net.http.ResponseSubscribers$HttpResponseInputStream.read(ResponseSubscribers.java:508) > at java.base/java.io.FilterInputStream.read(FilterInputStream.java:119) > at > org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientFilteredInputStream.read(HttpClientHTTPConduit.java:422) > at > java.base/java.io.SequenceInputStream.read(SequenceInputStream.java:197) > at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:333) > at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:376) > at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:219) > at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:173) > at java.base/java.io.InputStreamReader.read(InputStreamReader.java:189) > at java.base/java.io.Reader.read(Reader.java:265) > at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1610) > at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1589) > at org.apache.commons.io.IOUtils.copy(IOUtils.java:1384) > at org.apache.commons.io.IOUtils.copy(IOUtils.java:1153) > at org.apache.commons.io.IOUtils.toString(IOUtils.java:3105) > at LargeDataTester.main(LargeDataTester.java:84) > Caused by: java.io.IOException: selector manager closed > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.selectorClosedException(HttpClientImpl.java:1061) > at > java.net.http/jdk.internal.net.http.HttpClientImpl.closeSubscribers(HttpClientImpl.java:552) > at > java.net.http/jdk.internal.net.http.HttpClientImpl.stop(HttpClientImpl.java:543) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.shutdown(HttpClientImpl.java:1165) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1364) > {code} > > {color:#FF}*You can execute the code like so:*{color} > {code:java} > mvn compile exec:exec{code} > ℹ️ {*}Note{*}: You can do a diff between what works(Letting CXF deserialize > the object response payload automatically), and the last commit(Using > Response). > {code:java} > git diff HEAD^ HEAD {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8983) cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of cxf-rt-rs-security-jose-jaxrs
[ https://issues.apache.org/jira/browse/CXF-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8983: - Fix Version/s: 4.0.5 > cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of > cxf-rt-rs-security-jose-jaxrs > --- > > Key: CXF-8983 > URL: https://issues.apache.org/jira/browse/CXF-8983 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 4.0.4 >Reporter: Peter Palaga >Priority: Major > Fix For: 4.0.5 > > > cxf-services-sts-core does not need to depend on > cxf-rt-rs-security-jose-jaxrs; cxf-rt-rs-security-jose would be enough. > My understanding is that STS has nothing to do with JAX-RS, so there is no > need to pull any JAX-RS related code via cxf-rt-rs-security-jose-jaxrs. > cxf-services-sts-systests seem to pass when cxf-rt-rs-security-jose-jaxrs is > replaced by cxf-rt-rs-security-jose in cxf-services-sts-core. > Let me send a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-7396) CachedOutputStream doesn't delete temp files
[ https://issues.apache.org/jira/browse/CXF-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7396: - Fix Version/s: 4.0.5 (was: 4.0.4) > CachedOutputStream doesn't delete temp files > > > Key: CXF-7396 > URL: https://issues.apache.org/jira/browse/CXF-7396 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.8 >Reporter: Matthew Roth >Assignee: Andriy Redko >Priority: Minor > Fix For: 3.5.8, 3.6.3, 4.0.5 > > Attachments: HTTP Request.jmx, Screenshot 2020-05-05 at 10.09.43.png, > Screenshot 2020-05-12 at 12.42.11.png, image-2018-05-29-13-58-03-109.png, > image-2018-05-29-14-00-16-442.png, image-2018-05-29-14-00-54-215.png > > > In the CachedOutputStream the method maybeDeleteTempFile doesn't always > delete the temp file when it should. > > this.streamList.remove(stream) > Doesn't remove the stream, occasionally the stream is not in the list causing > the check of this.streamList().isEmpty() to fail. Also occurs when > this.streamList() contains multiple streams. > This seems occur when too many large requests are processed in a row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8983) cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of cxf-rt-rs-security-jose-jaxrs
[ https://issues.apache.org/jira/browse/CXF-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8983. -- Resolution: Fixed Thanks for the PR > cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of > cxf-rt-rs-security-jose-jaxrs > --- > > Key: CXF-8983 > URL: https://issues.apache.org/jira/browse/CXF-8983 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 4.0.4 >Reporter: Peter Palaga >Priority: Major > Fix For: 4.0.5 > > > cxf-services-sts-core does not need to depend on > cxf-rt-rs-security-jose-jaxrs; cxf-rt-rs-security-jose would be enough. > My understanding is that STS has nothing to do with JAX-RS, so there is no > need to pull any JAX-RS related code via cxf-rt-rs-security-jose-jaxrs. > cxf-services-sts-systests seem to pass when cxf-rt-rs-security-jose-jaxrs is > replaced by cxf-rt-rs-security-jose in cxf-services-sts-core. > Let me send a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8691) Logging Feature - Sensitive element with arrays
[ https://issues.apache.org/jira/browse/CXF-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8691: - Fix Version/s: 4.0.5 (was: 4.0.4) > Logging Feature - Sensitive element with arrays > --- > > Key: CXF-8691 > URL: https://issues.apache.org/jira/browse/CXF-8691 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.4.0, 3.5.1 >Reporter: Daniel >Assignee: Andriy Redko >Priority: Minor > Labels: Logging > Fix For: 3.5.8, 3.6.3, 4.0.5 > > > Hi, > I am trying to use the LoggingFeature within cxf-rt and hide sensitive > element names. > The code I use looks like the following: > > {code:java} > LoggingFeature loggingFeature = new LoggingFeature(); > loggingFeature.setLogBinary(false); > loggingFeature.setPrettyLogging(true); > loggingFeature.setLogMultipart(false); > loggingFeature.addSensitiveElementNames(new > HashSet<>(Arrays.asList("password"))); > {code} > Payload: > {code:java} > private final String shortName; > private final char[] password; > {code} > > Output: > > {code:java} > [services.MyWebservicePort.REQ_OUT] INFO - REQ_OUT > Address: http:// > HttpMethod: POST > Content-Type: application/json > ExchangeId: 560b73ae-e7e0-4687-9674-19ee72995a08 > Headers: {Accept=text/plain, Accept-Encoding=gzip;q=1.0, identity; q=0.5, > *;q=0, Content-Type=application/json} > Payload: > {"shortName":"UserName","password":["G","e","h","e","i","m","1","2","3","!"]} > {code} > As you can see, my password is not hidden in the output of the payload. It is > important to mention, that the field "password" in my code is declared as a > char-array. > However, if I add "shortName" to the sensetiveElementNames, everything works > as expected. The shortName is hidden (XXX), due to it beeing declared as a > String. > I looked at the source code an tracked the problem down to a regex. > "password" is not found, as the value is an array (MarkSensetiveHelper.java) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8763) Migrate to Jakarta WebSocket (from Jetty Websockets)
[ https://issues.apache.org/jira/browse/CXF-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8763: - Fix Version/s: 4.0.5 (was: 4.0.4) > Migrate to Jakarta WebSocket (from Jetty Websockets) > > > Key: CXF-8763 > URL: https://issues.apache.org/jira/browse/CXF-8763 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.5 > > > Migrate from Jetty WebSockets to Jakarta WebSockets -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8629) AsyncHTTPConduit (hc5) should support chunked request / response
[ https://issues.apache.org/jira/browse/CXF-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8629: - Fix Version/s: 4.0.5 (was: 4.0.4) > AsyncHTTPConduit (hc5) should support chunked request / response > > > Key: CXF-8629 > URL: https://issues.apache.org/jira/browse/CXF-8629 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.0, 3.4.5 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.5.8, 3.6.3, 4.0.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8675) jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade
[ https://issues.apache.org/jira/browse/CXF-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8675: - Fix Version/s: 4.0.5 (was: 4.0.4) > jakarta.xml.bind.ModuleUtil error after jaxb 3.0.1 upgrade > -- > > Key: CXF-8675 > URL: https://issues.apache.org/jira/browse/CXF-8675 > Project: CXF > Issue Type: Task > Components: Core >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.5 > > > SOAPRpcLitClientTypeTest throws the follow exception. > [INFO] Running org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest > jakarta.xml.ws.WebServiceException: > org.apache.cxf.service.factory.ServiceConstructionException > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:373) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) > at > org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:130) > at jakarta.xml.ws.Endpoint.publish(Endpoint.java:224) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitServerImpl.run(SOAPRpcLitServerImpl.java:33) > at > org.apache.cxf.testutil.common.AbstractTestServerBase.startInProcess(AbstractTestServerBase.java:44) > at > org.apache.cxf.testutil.common.ServerLauncher.launchServer(ServerLauncher.java:193) > at > org.apache.cxf.testutil.common.AbstractClientServerTestBase.launchServer(AbstractClientServerTestBase.java:91) > at > org.apache.cxf.systest.type_test.soap.SOAPRpcLitClientTypeTest.startServers(SOAPRpcLitClientTypeTest.java:45) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162) > at > org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548) > Caused by: org.apache.cxf.service.factory.ServiceConstructionException > at > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:360) > at > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:87) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:425) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527) > at > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262) > at > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > at > org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) > at > org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:210) > at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:458) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:336) > ... 28 more > Caused by: jakarta.xml.bind.JAXBException: Package javax.xml.namespace with > Jakarta XM
[jira] [Assigned] (CXF-8981) WSS4J Encyption using the Key Agreement Method with the apache-CXF
[ https://issues.apache.org/jira/browse/CXF-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8981: Assignee: Colm O hEigeartaigh > WSS4J Encyption using the Key Agreement Method with the apache-CXF > --- > > Key: CXF-8981 > URL: https://issues.apache.org/jira/browse/CXF-8981 > Project: CXF > Issue Type: Test > Components: WS-* Components >Affects Versions: 4.0.3 >Reporter: Joze Rihtarsic >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.4 > > > Recently, the Santuario/XMLSEC and WSS4J libraries added the support for the > Key Agreement method. See the following tickets: SANTUARIO-511 and WSS-706. > The purpose of this task is to implement tests within the cxf library to > verify that the Key Agreement method for encryption with EC and XEC keys is > working as expected with the CXF framework. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8977) Add support for MTOM Serialization Policy Assertion 1.1
[ https://issues.apache.org/jira/browse/CXF-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818809#comment-17818809 ] Colm O hEigeartaigh commented on CXF-8977: -- It's a working draft from 2007, was it ever published? [https://www.w3.org/TR/soap12-mtom-policy/] > Add support for MTOM Serialization Policy Assertion 1.1 > --- > > Key: CXF-8977 > URL: https://issues.apache.org/jira/browse/CXF-8977 > Project: CXF > Issue Type: New Feature > Components: WS-* Components >Affects Versions: 4.0.3 >Reporter: Daniel Spilker >Priority: Major > > When trying to consume a WSDL containing a MTOM Serialization Policy > Assertion 1.1 (https://www.w3.org/TR/soap12-mtom-policy/) a warning is logged > and an exception is thrown. > {code} > Feb. 13, 2024 7:10:47 AM > org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl > handleNoRegisteredBuilder > WARNUNG: No assertion builder for type > {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM registered. > jakarta.xml.ws.soap.SOAPFaultException: None of the policy alternatives can > be satisfied. > at > org.apache.cxf.jaxws.JaxWsClientProxy.mapException(JaxWsClientProxy.java:195) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145) > at jdk.proxy2/jdk.proxy2.$Proxy48.listShipments(Unknown Source) > at > com.example.shipment.adapters.TransferServiceAdapter.listShipments(TransferServiceAdapter.java:52) > at > com.example.shipment.adapters.TransferServiceAdapterTest.testListShipments(TransferServiceAdapterTest.java:39) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > Caused by: org.apache.cxf.ws.policy.PolicyException: None of the policy > alternatives can be satisfied. > at > org.apache.cxf.ws.policy.EndpointPolicyImpl.chooseAlternative(EndpointPolicyImpl.java:172) > at > org.apache.cxf.ws.policy.EndpointPolicyImpl.finalizeConfig(EndpointPolicyImpl.java:146) > at > org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:142) > at > org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:614) > at > org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:326) > at > org.apache.cxf.ws.policy.PolicyEngineImpl.getClientEndpointPolicy(PolicyEngineImpl.java:313) > at > org.apache.cxf.ws.policy.PolicyDataEngineImpl.getClientEndpointPolicy(PolicyDataEngineImpl.java:61) > at > org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:372) > at > org.apache.cxf.transport.http.HTTPConduit.updateClientPolicy(HTTPConduit.java:392) > at > org.apache.cxf.transport.http.HTTPConduit.getClient(HTTPConduit.java:938) > at > org.apache.cxf.transport.http.HTTPConduit.configureConduitFromEndpointInfo(HTTPConduit.java:414) > at > org.apache.cxf.transport.http.HTTPConduit.finalizeConfig(HTTPConduit.java:494) > at > org.apache.cxf.transport.http.HTTPTransportFactory.getConduit(HTTPTransportFactory.java:257) > at > org.apache.cxf.binding.soap.SoapTransportFactory.getConduit(SoapTransportFactory.java:226) > at > org.apache.cxf.endpoint.AbstractConduitSelector.createConduit(AbstractConduitSelector.java:151) > at > org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:108) > at > org.apache.cxf.endpoint.UpfrontConduitSelector.prepare(UpfrontConduitSelector.java:63) > at > org.apache.cxf.endpoint.ClientImpl.prepareConduitSelector(ClientImpl.java:885) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:523) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:439) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:354) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:312) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140) > ... 6 more > {code} > WSDL: > {code} > > http://www.example.com/namespace"; > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > xmlns:wsoma="http://www.w3.org/2007/08/soap12-mtom-policy"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; > targetNamespace="http://www.example.com/namespace";> > > type="example:TransferServicePortType"> > > > > >
[jira] [Resolved] (FEDIZ-256) Tomcat authenticationSessionTimeout
[ https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-256. --- Resolution: Fixed > Tomcat authenticationSessionTimeout > --- > > Key: FEDIZ-256 > URL: https://issues.apache.org/jira/browse/FEDIZ-256 > Project: CXF-Fediz > Issue Type: Bug > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Tomas Milian >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 1.6.2 > > > Hello, > I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue. > Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute > (authenticationSessionTimeout) that breaks Fediz authentication process. > {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change > introduced in Tomcat 9.0.74 replaces the original session timeout with the > authenticationSessionTimeout default value (120 seconds).{color} > {code:java} > if (session instanceof HttpSession && ((HttpSession) > session).isNew()) { > int originalMaxInactiveInterval = > session.getMaxInactiveInterval(); > if (originalMaxInactiveInterval > > getAuthenticationSessionTimeout()) { > > saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); > > session.setMaxInactiveInterval(getAuthenticationSessionTimeout()); > } > } {code} > {color:#172b4d}Once the Fediz authentication is resumed, the original session > maxInactiveInterval is not restored, so authenticated session always ends up > with a 120 second maxInactiveInterval{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FEDIZ-256) Tomcat authenticationSessionTimeout
[ https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated FEDIZ-256: -- Fix Version/s: 1.6.2 > Tomcat authenticationSessionTimeout > --- > > Key: FEDIZ-256 > URL: https://issues.apache.org/jira/browse/FEDIZ-256 > Project: CXF-Fediz > Issue Type: Bug > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Tomas Milian >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 1.6.2 > > > Hello, > I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue. > Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute > (authenticationSessionTimeout) that breaks Fediz authentication process. > {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change > introduced in Tomcat 9.0.74 replaces the original session timeout with the > authenticationSessionTimeout default value (120 seconds).{color} > {code:java} > if (session instanceof HttpSession && ((HttpSession) > session).isNew()) { > int originalMaxInactiveInterval = > session.getMaxInactiveInterval(); > if (originalMaxInactiveInterval > > getAuthenticationSessionTimeout()) { > > saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); > > session.setMaxInactiveInterval(getAuthenticationSessionTimeout()); > } > } {code} > {color:#172b4d}Once the Fediz authentication is resumed, the original session > maxInactiveInterval is not restored, so authenticated session always ends up > with a 120 second maxInactiveInterval{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FEDIZ-256) Tomcat authenticationSessionTimeout
[ https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782173#comment-17782173 ] Colm O hEigeartaigh commented on FEDIZ-256: --- We have a new fix in Tomcat - maybe this fixes the problem? [https://github.com/apache/tomcat/commit/cd58739d64cba52dfc96a3aba6a180adea1ab020] > Tomcat authenticationSessionTimeout > --- > > Key: FEDIZ-256 > URL: https://issues.apache.org/jira/browse/FEDIZ-256 > Project: CXF-Fediz > Issue Type: Bug > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Tomas Milian >Assignee: Colm O hEigeartaigh >Priority: Major > > Hello, > I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue. > Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute > (authenticationSessionTimeout) that breaks Fediz authentication process. > {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change > introduced in Tomcat 9.0.74 replaces the original session timeout with the > authenticationSessionTimeout default value (120 seconds).{color} > {code:java} > if (session instanceof HttpSession && ((HttpSession) > session).isNew()) { > int originalMaxInactiveInterval = > session.getMaxInactiveInterval(); > if (originalMaxInactiveInterval > > getAuthenticationSessionTimeout()) { > > saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); > > session.setMaxInactiveInterval(getAuthenticationSessionTimeout()); > } > } {code} > {color:#172b4d}Once the Fediz authentication is resumed, the original session > maxInactiveInterval is not restored, so authenticated session always ends up > with a 120 second maxInactiveInterval{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8952) HttpClientHTTPConduit in CXF doesn't support TLSv1.3 along with other protocols
[ https://issues.apache.org/jira/browse/CXF-8952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782106#comment-17782106 ] Colm O hEigeartaigh commented on CXF-8952: -- Is it supported by undertow? We don't have TLS v1.3 here either: https://github.com/apache/cxf/blob/8b205c8086aeb1f5514472f0802c1fb7d510a50e/rt/transports/http-undertow/src/main/java/org/apache/cxf/transport/http_undertow/UndertowHTTPServerEngine.java#L302 > HttpClientHTTPConduit in CXF doesn't support TLSv1.3 along with other > protocols > --- > > Key: CXF-8952 > URL: https://issues.apache.org/jira/browse/CXF-8952 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.6.2, 4.0.3 >Reporter: Sebastian Violet >Assignee: Daniel Kulp >Priority: Critical > Fix For: 3.6.3, 4.0.4 > > Attachments: image-2023-10-30-17-30-19-307.png > > > *HttpClientHTTPConduit* does't have support for TLSv1.3 out of the box. > [Look at line #253 > here|https://github.com/apache/cxf/blob/ee4244116cb49c007bde3ee7ee6a06a4cfb26027/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L253]. > !image-2023-10-30-17-30-19-307.png|width=821,height=227! > This means that any endpoint which solely supports *TLSv1.3* and has turned > off other lower protocols will fail SSL Handshake. > One can pass in a singular {*}secureSocketProtocol{*}, but that doesn't > support passing in a list for negotiation fallback. > I.e. We can do the following: > {code:java} > ClientConfiguration config = WebClient.getConfig(service); > final TLSClientParameters tlsClientParameters = > ObjectUtils.firstNonNull(config.getHttpConduit().getTlsClientParameters(), > new TLSClientParameters()); > tlsClientParameters.setSecureSocketProtocol("TLSv1.3"); > {code} > However, this will not work with endpoints that do now support {*}TLSv1.3{*}; > it works great for endpoints that only have *TLSv1.3* though. > > {*}Solution{*}: > {*}Option 1{*}({color:#FF}Ideal; *recommended*{color}): Add *TLSv1.3* to > the list of protocols when creating the HttpClient through the builder. > {*}Option 2{*}: Allow *setSecureSocketProtocol* to take in an *array* of > protocols. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8949) Move CxfMessageHeadersRelayTest to camel-cxf-soap
[ https://issues.apache.org/jira/browse/CXF-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779069#comment-17779069 ] Colm O hEigeartaigh commented on CXF-8949: -- [~ppalaga] - did you mean to create this in the Camel Jira project? > Move CxfMessageHeadersRelayTest to camel-cxf-soap > - > > Key: CXF-8949 > URL: https://issues.apache.org/jira/browse/CXF-8949 > Project: CXF > Issue Type: Bug >Reporter: Peter Palaga >Priority: Major > > The named test currently lives under > [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] > but there does not seem to be anything Spring specific in the test. Moreover > it is cited on the CXF component page > https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. > > We should attempt to move the test to > [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FEDIZ-256) Tomcat authenticationSessionTimeout
[ https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-256: - Assignee: Colm O hEigeartaigh > Tomcat authenticationSessionTimeout > --- > > Key: FEDIZ-256 > URL: https://issues.apache.org/jira/browse/FEDIZ-256 > Project: CXF-Fediz > Issue Type: Bug > Components: Plugin >Affects Versions: 1.6.1 >Reporter: Tomas Milian >Assignee: Colm O hEigeartaigh >Priority: Major > > Hello, > I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue. > Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute > (authenticationSessionTimeout) that breaks Fediz authentication process. > {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change > introduced in Tomcat 9.0.74 replaces the original session timeout with the > authenticationSessionTimeout default value (120 seconds).{color} > {code:java} > if (session instanceof HttpSession && ((HttpSession) > session).isNew()) { > int originalMaxInactiveInterval = > session.getMaxInactiveInterval(); > if (originalMaxInactiveInterval > > getAuthenticationSessionTimeout()) { > > saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval); > > session.setMaxInactiveInterval(getAuthenticationSessionTimeout()); > } > } {code} > {color:#172b4d}Once the Fediz authentication is resumed, the original session > maxInactiveInterval is not restored, so authenticated session always ends up > with a 120 second maxInactiveInterval{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8930) Example showing enabling HTTPS programmatically through code.
[ https://issues.apache.org/jira/browse/CXF-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8930: Assignee: Colm O hEigeartaigh > Example showing enabling HTTPS programmatically through code. > - > > Key: CXF-8930 > URL: https://issues.apache.org/jira/browse/CXF-8930 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.13 >Reporter: George McCone >Assignee: Colm O hEigeartaigh >Priority: Minor > > In our system, we dynamically standup multiple Endpoints programmatically and > do not use any of the bean xml configuration. > We have been successfully using CXF for open HTTP enpoints, but recently have > been switching over to HTTPS. > All the documentation and examples we can find in the [Apache CXF -- Jetty > Configuration|https://cxf.apache.org/docs/jetty-configuration.html] and > examples at > [wsdl_first_https|https://github.com/apache/cxf/blob/main/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java] > are all using spring configuration files. > Looking to have an example that shows HTTPS configuration without the use of > any external configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8930) Example showing enabling HTTPS programmatically through code.
[ https://issues.apache.org/jira/browse/CXF-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8930. -- Resolution: Information Provided > Example showing enabling HTTPS programmatically through code. > - > > Key: CXF-8930 > URL: https://issues.apache.org/jira/browse/CXF-8930 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.13 >Reporter: George McCone >Assignee: Colm O hEigeartaigh >Priority: Minor > > In our system, we dynamically standup multiple Endpoints programmatically and > do not use any of the bean xml configuration. > We have been successfully using CXF for open HTTP enpoints, but recently have > been switching over to HTTPS. > All the documentation and examples we can find in the [Apache CXF -- Jetty > Configuration|https://cxf.apache.org/docs/jetty-configuration.html] and > examples at > [wsdl_first_https|https://github.com/apache/cxf/blob/main/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java] > are all using spring configuration files. > Looking to have an example that shows HTTPS configuration without the use of > any external configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8930) Example showing enabling HTTPS programmatically through code.
[ https://issues.apache.org/jira/browse/CXF-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766830#comment-17766830 ] Colm O hEigeartaigh commented on CXF-8930: -- This might be what you want? [https://github.com/apache/cxf/blob/2b8a745b4087609166c3fcfa8946da1adca16d76/systests/transports/src/test/java/org/apache/cxf/systest/https/trust/TrustServerNoSpring.java#L4] > Example showing enabling HTTPS programmatically through code. > - > > Key: CXF-8930 > URL: https://issues.apache.org/jira/browse/CXF-8930 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.3.13 >Reporter: George McCone >Priority: Minor > > In our system, we dynamically standup multiple Endpoints programmatically and > do not use any of the bean xml configuration. > We have been successfully using CXF for open HTTP enpoints, but recently have > been switching over to HTTPS. > All the documentation and examples we can find in the [Apache CXF -- Jetty > Configuration|https://cxf.apache.org/docs/jetty-configuration.html] and > examples at > [wsdl_first_https|https://github.com/apache/cxf/blob/main/distribution/src/main/release/samples/wsdl_first_https/src/main/java/demo/hw_https/server/Server.java] > are all using spring configuration files. > Looking to have an example that shows HTTPS configuration without the use of > any external configuration files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8817) Add support for Micrometer Observation
[ https://issues.apache.org/jira/browse/CXF-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764974#comment-17764974 ] Colm O hEigeartaigh commented on CXF-8817: -- [~reta] Should the fix version be bumped? > Add support for Micrometer Observation > -- > > Key: CXF-8817 > URL: https://issues.apache.org/jira/browse/CXF-8817 > Project: CXF > Issue Type: New Feature > Components: Core >Reporter: Marcin Grzejszczak >Priority: Major > Fix For: 4.0.3 > > > I'm a co-maintainer of Spring Cloud Sleuth and Micrometer projects (together > with Tommy Ludwig and Jonatan Ivanov). > [Micrometer Observation|https://micrometer.io/docs/observation] is coming as > part of the Micrometer 1.10 release and [Micrometer > Tracing|https://micrometer.io/docs/tracing] is a new project. The idea of > Micrometer Observation is that you instrument code once but you get multiple > benefits out of it - e.g. you can get tracing, metrics, logging or whatever > you see fit). > Since this project already supports Micrometer I was curious if there's > interest in adding Micrometer Observation support so that automatically (when > on classpath) except for metrics, spans could be created and tracing context > propagation could happen too. In other words metrics and tracing of this > project could be created + if there are Micrometer Observation compatible > projects, then they will join the whole graph (e.g. whole Spring Framework 6 > is, Apache Dubbo, Resilience4j etc.). > If there's interest in adding that feature, I can provide a PR. > Documentation: > * > [https://cwiki.apache.org/confluence/display/CXF20DOC/Using+Micrometer+Observation] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8916) Replacement for StaxUtils.setInnerElementCountThreshold
[ https://issues.apache.org/jira/browse/CXF-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8916: Assignee: Colm O hEigeartaigh > Replacement for StaxUtils.setInnerElementCountThreshold > --- > > Key: CXF-8916 > URL: https://issues.apache.org/jira/browse/CXF-8916 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 3.4.0 >Reporter: Rich M >Assignee: Colm O hEigeartaigh >Priority: Minor > > This is related to CXF-8273, where following method was removed from code: > public static void setInnerElementCountThreshold(int i) > Description also states - "Instead, set the system properties to customize > how we restrict XML." > If I set property just like this, would it be effective ? > {color:#1d1c1d}System.setProperty("com.ctc.wstx.maxChildrenPerElement", > "10");{color} > {color:#1d1c1d}or should it be:{color} > {color:#1d1c1d}{color:#1d1c1d}System.setProperty("org.apache.cxf.stax.maxChildElements", > "10");{color}{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8916) Replacement for StaxUtils.setInnerElementCountThreshold
[ https://issues.apache.org/jira/browse/CXF-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8916. -- Resolution: Not A Problem > Replacement for StaxUtils.setInnerElementCountThreshold > --- > > Key: CXF-8916 > URL: https://issues.apache.org/jira/browse/CXF-8916 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 3.4.0 >Reporter: Rich M >Priority: Minor > > This is related to CXF-8273, where following method was removed from code: > public static void setInnerElementCountThreshold(int i) > Description also states - "Instead, set the system properties to customize > how we restrict XML." > If I set property just like this, would it be effective ? > {color:#1d1c1d}System.setProperty("com.ctc.wstx.maxChildrenPerElement", > "10");{color} > {color:#1d1c1d}or should it be:{color} > {color:#1d1c1d}{color:#1d1c1d}System.setProperty("org.apache.cxf.stax.maxChildElements", > "10");{color}{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8916) Replacement for StaxUtils.setInnerElementCountThreshold
[ https://issues.apache.org/jira/browse/CXF-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762122#comment-17762122 ] Colm O hEigeartaigh commented on CXF-8916: -- Please see here [https://cxf.apache.org/docs/security.html#Security-ControllingLargeRequestPayloads] "These settings can be set as Bus level properties, endpoint level properties, or even per request via an interceptor." Here's an example I think [https://github.com/apache/cxf/blob/d1396f4ce4ffb890b2434930402a8890094d7079/systests/forked/src/test/java/org/apache/cxf/systests/forked/dispatch/DispatchClientServerWithHugeResponseTest.java#L93] > Replacement for StaxUtils.setInnerElementCountThreshold > --- > > Key: CXF-8916 > URL: https://issues.apache.org/jira/browse/CXF-8916 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 3.4.0 >Reporter: Rich M >Priority: Minor > > This is related to CXF-8273, where following method was removed from code: > public static void setInnerElementCountThreshold(int i) > Description also states - "Instead, set the system properties to customize > how we restrict XML." > If I set property just like this, would it be effective ? > {color:#1d1c1d}System.setProperty("com.ctc.wstx.maxChildrenPerElement", > "10");{color} > {color:#1d1c1d}or should it be:{color} > {color:#1d1c1d}{color:#1d1c1d}System.setProperty("org.apache.cxf.stax.maxChildElements", > "10");{color}{color} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8922) @Multipart for type java.lang.Integer returning null
[ https://issues.apache.org/jira/browse/CXF-8922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761948#comment-17761948 ] Colm O hEigeartaigh commented on CXF-8922: -- Can you create a test-case to reproduce the problem? > @Multipart for type java.lang.Integer returning null > > > Key: CXF-8922 > URL: https://issues.apache.org/jira/browse/CXF-8922 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.5 >Reporter: Lef >Priority: Major > > In version 3.3.5 this code was working fine (index & total were returned as > Integer) > {code:java} > @Path("/uploadFiles") > @POST > @Consumes({MediaType.MULTIPART_FORM_DATA}) > public void uploadFile(@Context HttpServletRequest httpServletRequest, >@Context HttpServletResponse httpServletResponse, >@Multipart(value = "file", required = false) > Attachment file, >@Multipart(value = "dzchunkindex", required = false) > Integer index, >@Multipart(value = "dztotalchunkcount", required = > false) Integer total, >@QueryParam(value = "path") String path) {code} > after upgrading to 3.5.5 index and total are always returned null. > Changing the type from Integer to String fixes my issue. Is this expected > functionality? > I've debugged this down to MultipartProvider#fromAttachment line 233 where > MessageBodyReader is null -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8913) Avoid 3rd party maven repository for OpenSAML
[ https://issues.apache.org/jira/browse/CXF-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755823#comment-17755823 ] Colm O hEigeartaigh commented on CXF-8913: -- I'll experiment [~reta] to see if I can isolate OpenSAML to a separate module in WSS4J, it'll be a couple of weeks though before I can get around to it. > Avoid 3rd party maven repository for OpenSAML > - > > Key: CXF-8913 > URL: https://issues.apache.org/jira/browse/CXF-8913 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 4.0.2 >Reporter: Claus Ibsen >Priority: Major > > Apache CXF depends on OpenSAML from Apache WSSJ project > However this commit causes wss4j to download JARs from NOT maven central but > from > https://build.shibboleth.net/nexus/content/groups/public > https://github.com/apache/ws-wss4j/commit/e4a33efcb2b474a1da2b2c08f815b2718e111823 > Is there a way for Apache CXF to only use JARs from maven central. There is a > trust issue when JARs are NOT downloaded from central. > At Apache Camel we only download from maven central - except for camel-jira > which sadly had to download from Atlassian. We are considering deprecating > and removing this component for that reason. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8835) Upgrade to Spring 5.3.26
[ https://issues.apache.org/jira/browse/CXF-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8835: - Fix Version/s: 3.5.6 (was: 3.5.5) > Upgrade to Spring 5.3.26 > > > Key: CXF-8835 > URL: https://issues.apache.org/jira/browse/CXF-8835 > Project: CXF > Issue Type: Improvement >Reporter: Ashok Pai >Priority: Major > Fix For: 3.5.6 > > > Spring framework contains a security bypass vulnerability when {{**}} is used > as a pattern in Spring Security configuration with the {{mvcRequestMatcher}} > component. The potential for security bypass exists due to the mismatch in > pattern matching between Spring Security and Spring MVC and this has been > fixed in 5.3.26. > Apache cxf 3.5.5 is present with spring version 5.3.22. Please provide > updated Apache CXF with latest (5.3.26) spring framework jars/classes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8837) Allow P11 RSA Keys within JwsUtils
[ https://issues.apache.org/jira/browse/CXF-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8837. -- Resolution: Fixed > Allow P11 RSA Keys within JwsUtils > -- > > Key: CXF-8837 > URL: https://issues.apache.org/jira/browse/CXF-8837 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4, 4.0.0 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.6.0, 4.0.1, 3.5.6 > > > As discussed on the [mailing > list|[https://lists.apache.org/thread/95hcbjqy7z7m7qhz407y9o36gw2ql2xo],] the > current implementation within `JwsUtils` only accepts RSA keys coming from a > local keystore file. RSA keys from other resources like a HSM via PKCS11 > interface are getting rejected currently for no reason. > The code needs some refactoring to not limit the support to local keystores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8837) Allow P11 RSA Keys within JwsUtils
[ https://issues.apache.org/jira/browse/CXF-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8837: - Fix Version/s: 3.6.0 3.5.6 > Allow P11 RSA Keys within JwsUtils > -- > > Key: CXF-8837 > URL: https://issues.apache.org/jira/browse/CXF-8837 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4, 4.0.0 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.6.0, 4.0.1, 3.5.6 > > > As discussed on the [mailing > list|[https://lists.apache.org/thread/95hcbjqy7z7m7qhz407y9o36gw2ql2xo],] the > current implementation within `JwsUtils` only accepts RSA keys coming from a > local keystore file. RSA keys from other resources like a HSM via PKCS11 > interface are getting rejected currently for no reason. > The code needs some refactoring to not limit the support to local keystores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8837) Allow P11 RSA Keys within JwsUtils
[ https://issues.apache.org/jira/browse/CXF-8837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8837: Assignee: Colm O hEigeartaigh (was: Jan Bernhardt) > Allow P11 RSA Keys within JwsUtils > -- > > Key: CXF-8837 > URL: https://issues.apache.org/jira/browse/CXF-8837 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.3.4, 4.0.0 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.1 > > > As discussed on the [mailing > list|[https://lists.apache.org/thread/95hcbjqy7z7m7qhz407y9o36gw2ql2xo],] the > current implementation within `JwsUtils` only accepts RSA keys coming from a > local keystore file. RSA keys from other resources like a HSM via PKCS11 > interface are getting rejected currently for no reason. > The code needs some refactoring to not limit the support to local keystores. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8835) Upgrade to Spring 5.3.26
[ https://issues.apache.org/jira/browse/CXF-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8835. -- Resolution: Fixed We have already updated to 5.3.27 which will be in the next release, which we are wrapping up soon https://github.com/apache/cxf/commit/39b3a4d4a996307db7a1228a2ec0ff5ca8e0e7b7 > Upgrade to Spring 5.3.26 > > > Key: CXF-8835 > URL: https://issues.apache.org/jira/browse/CXF-8835 > Project: CXF > Issue Type: Improvement >Reporter: Ashok Pai >Priority: Major > Fix For: 3.5.5 > > > There are few vulnerabilities been reported with Spring 5.3.23. Apache cxf > 3.5.5 is present with spring version 5.3.22. Please provide updated Apache > CXF with latest (5.3.26) spring framework jars/classes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8835) Upgrade to Spring 5.3.26
[ https://issues.apache.org/jira/browse/CXF-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8835: - Fix Version/s: 3.5.5 > Upgrade to Spring 5.3.26 > > > Key: CXF-8835 > URL: https://issues.apache.org/jira/browse/CXF-8835 > Project: CXF > Issue Type: Improvement >Reporter: Ashok Pai >Priority: Major > Fix For: 3.5.5 > > > There are few vulnerabilities been reported with Spring 5.3.23. Apache cxf > 3.5.5 is present with spring version 5.3.22. Please provide updated Apache > CXF with latest (5.3.26) spring framework jars/classes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697533#comment-17697533 ] Colm O hEigeartaigh commented on CXF-8823: -- [~hlin] Apache CXF uses Apache Santuario for XML Security - [https://santuario.apache.org/] I'm the PMC chair of that project, IMO it would be a very good candidate for fuzzing, as the API is quite straightforward. The WS-Security stack could also be tested in CXF, see this unit test: [https://github.com/apache/cxf/blob/main/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/WSS4JInOutTest.java] > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696694#comment-17696694 ] Colm O hEigeartaigh commented on CXF-8823: -- [~hlin] Any issues found should be submitted to priv...@cxf.apache.org. > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696693#comment-17696693 ] Colm O hEigeartaigh commented on CXF-8823: -- [~reta] Any ideas here for unit tests we could point to? I'm more used to working with the system tests, which maybe aren't appropriate here. > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8823) Integrating Apache-CXF into OSS-Fuzz
[ https://issues.apache.org/jira/browse/CXF-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696181#comment-17696181 ] Colm O hEigeartaigh commented on CXF-8823: -- Thanks [~hlin] . Looking at the Pr it seems the JsonMapObjectReaderWriter and AttachmentSerializer were selected, why these two in particular? It would be cool if we could fuzz the process of parsing a complete REST and/or SOAP request as well. > Integrating Apache-CXF into OSS-Fuzz > > > Key: CXF-8823 > URL: https://issues.apache.org/jira/browse/CXF-8823 > Project: CXF > Issue Type: Improvement >Reporter: Henry Lin >Priority: Major > > Hi all, > We have prepared the [initial > integration|https://github.com/google/oss-fuzz/pull/9853] of Apache-CXF into > [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more > security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project committer > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How can Code Intelligence support you?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8818) wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
[ https://issues.apache.org/jira/browse/CXF-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8818. -- Resolution: Fixed > wsdl2java fails in 4.0.0 due to incorrect versions in Manifest > -- > > Key: CXF-8818 > URL: https://issues.apache.org/jira/browse/CXF-8818 > Project: CXF > Issue Type: Bug >Affects Versions: 4.0.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Critical > Fix For: 4.0.1 > > > wsdl2java fails in 4.0.0 due to incorrect versions in Manifest > {code:java} > aused by: java.lang.ClassNotFoundException: jakarta.xml.ws.Service > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8818) wsdl2java fails in 4.0.0 due to incorrect versions in Manifest
Colm O hEigeartaigh created CXF-8818: Summary: wsdl2java fails in 4.0.0 due to incorrect versions in Manifest Key: CXF-8818 URL: https://issues.apache.org/jira/browse/CXF-8818 Project: CXF Issue Type: Bug Affects Versions: 4.0.0 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 4.0.1 wsdl2java fails in 4.0.0 due to incorrect versions in Manifest {code:java} aused by: java.lang.ClassNotFoundException: jakarta.xml.ws.Service at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8767) Not expected behavior with java2ws-plugin
[ https://issues.apache.org/jira/browse/CXF-8767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649601#comment-17649601 ] Colm O hEigeartaigh commented on CXF-8767: -- [~ffang] - Can you check this please, as the description references a commit you made? > Not expected behavior with java2ws-plugin > - > > Key: CXF-8767 > URL: https://issues.apache.org/jira/browse/CXF-8767 > Project: CXF > Issue Type: Bug > Components: Documentation, Tooling >Affects Versions: 3.2.8, 3.5.3 >Reporter: Thomas Sergent >Priority: Major > > Hi, after upgrading from CXF 3.0.16 to 3.5.3 I found an issue with > {code} > org.apache.cxf > cxf-java2ws-plugin > {code} > The attach wsdl feature is now broken and/or not ok according to the > documentation. The artifcat type is no more wlsdl but the file name of the > output wsdl. > This bug has been introduced by this commit : > https://github.com/apache/cxf/commit/9597cfb0fe57b55cffd6569efd98c69108e7befe > (https://issues.apache.org/jira/browse/CXF-7924) > Please update the documentation to precise the real artifact type or change > the implementation / plugin to be able to customize it ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8808) broken link at guide page
[ https://issues.apache.org/jira/browse/CXF-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8808. -- Resolution: Fixed Thanks for reporting, should be fixed now. > broken link at guide page > - > > Key: CXF-8808 > URL: https://issues.apache.org/jira/browse/CXF-8808 > Project: CXF > Issue Type: Bug > Components: Documentation >Reporter: Gernot Hueller >Assignee: Colm O hEigeartaigh >Priority: Trivial > > on > [https://cxf.apache.org/docs/application-server-specific-configuration-guide.html] > there is "rely on JBossWS integration and the Apache CXF libraries included > in the application server > ([documentation|https://docs.jboss.org/author/display/AS71/Webservices+reference+guide]): > " > link leads to > [https://docs.jboss.org/author/display/AS71/Webservices+reference+guide] > which is dead > in fact, all the links in this paragraph are dead. Would be nice if they > weren't -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8804) Fix org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses
[ https://issues.apache.org/jira/browse/CXF-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649563#comment-17649563 ] Colm O hEigeartaigh commented on CXF-8804: -- [~reta] Should this and the other open 4.0.0 tasks be moved to 4.0.1? > Fix > org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses > -- > > Key: CXF-8804 > URL: https://issues.apache.org/jira/browse/CXF-8804 > Project: CXF > Issue Type: Sub-task >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > h1. Regression > Build / Matrix - JAVA_VERSION = 'jdk_17_latest' / JDK specific build / Build > & Test / > org.apache.cxf.systest.jaxrs.failover.FailoverTest.testSequentialStrategyWithDiffBaseAddresses > > h3. Error Message > Illegal status value : -1 > h3. Stacktrace > java.lang.IllegalArgumentException: Illegal status value : -1 at > org.apache.cxf.jaxrs.impl.ResponseBuilderImpl.validateStatusCode(ResponseBuilderImpl.java:94) > at > org.apache.cxf.jaxrs.impl.ResponseBuilderImpl.status(ResponseBuilderImpl.java:78) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.toResponseBuilder(JAXRSUtils.java:1974) > at > org.apache.cxf.jaxrs.client.AbstractClient.setResponseBuilder(AbstractClient.java:434) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:1022) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:932) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:347) > at > org.apache.cxf.common.util.CglibProxyHelper$1.intercept(CglibProxyHelper.java:67) > at > org.apache.cxf.systest.jaxrs.BookStore$$EnhancerByCGLIB$$ad035b93.echoBookElementJson() > at > org.apache.cxf.systest.jaxrs.failover.AbstractFailoverTest.strategyTest(AbstractFailoverTest.java:245) > at > org.apache.cxf.systest.jaxrs.failover.AbstractFailoverTest.testSequentialStrategyWithDiffBaseAddresses(AbstractFailoverTest.java:144) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:568) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at > org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.ParentRunner.run(ParentRunner.java:413) at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169) > at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8808) broken link at guide page
[ https://issues.apache.org/jira/browse/CXF-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8808: Assignee: Colm O hEigeartaigh > broken link at guide page > - > > Key: CXF-8808 > URL: https://issues.apache.org/jira/browse/CXF-8808 > Project: CXF > Issue Type: Bug > Components: Documentation >Reporter: Gernot Hueller >Assignee: Colm O hEigeartaigh >Priority: Trivial > > on > [https://cxf.apache.org/docs/application-server-specific-configuration-guide.html] > there is "rely on JBossWS integration and the Apache CXF libraries included > in the application server > ([documentation|https://docs.jboss.org/author/display/AS71/Webservices+reference+guide]): > " > link leads to > [https://docs.jboss.org/author/display/AS71/Webservices+reference+guide] > which is dead > in fact, all the links in this paragraph are dead. Would be nice if they > weren't -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8777. -- Resolution: Fixed > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5, 3.4.10 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8755) Update to Slf4j 2.0
[ https://issues.apache.org/jira/browse/CXF-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626507#comment-17626507 ] Colm O hEigeartaigh commented on CXF-8755: -- Makes sense, thanks [~reta] > Update to Slf4j 2.0 > --- > > Key: CXF-8755 > URL: https://issues.apache.org/jira/browse/CXF-8755 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > [https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0] > https://www.slf4j.org/faq.html#changesInVersion200 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CXF-8779) Vulnerabilities from dependencies - jackson-databind & commons-text
[ https://issues.apache.org/jira/browse/CXF-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8779. Resolution: Not A Problem > Vulnerabilities from dependencies - jackson-databind & commons-text > --- > > Key: CXF-8779 > URL: https://issues.apache.org/jira/browse/CXF-8779 > Project: CXF > Issue Type: Bug >Reporter: Ragul >Priority: Critical > > Version 1.11.1 of avro-compiler contains the apache commons-text vulnerable > library (1.9) & > Jackson-databind (2.12.7) > > Vulnerabilities from dependencies: > [CVE-2022-42889|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42889] > [CVE-2022-42004|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42004] > [CVE-2022-42003|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42003] > > Is there any plan to upgrade dependency and address this issue? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625047#comment-17625047 ] Colm O hEigeartaigh commented on CXF-8777: -- Likely mid-December > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5, 3.4.10 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8755) Update to Slf4j 2.0
[ https://issues.apache.org/jira/browse/CXF-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625044#comment-17625044 ] Colm O hEigeartaigh commented on CXF-8755: -- Maybe we could update as well 3.5.x? SLF4J 1.7.x is EOL afaik. Colm. > Update to Slf4j 2.0 > --- > > Key: CXF-8755 > URL: https://issues.apache.org/jira/browse/CXF-8755 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0 > > > [https://mvnrepository.com/artifact/org.slf4j/slf4j-api/2.0.0] > https://www.slf4j.org/faq.html#changesInVersion200 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8777: - Fix Version/s: 3.4.10 > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5, 3.4.10 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8778) Upgrade commons-text to address CVE-2022-42889
[ https://issues.apache.org/jira/browse/CXF-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8778. -- Resolution: Duplicate > Upgrade commons-text to address CVE-2022-42889 > -- > > Key: CXF-8778 > URL: https://issues.apache.org/jira/browse/CXF-8778 > Project: CXF > Issue Type: Bug >Affects Versions: 3.5.4, 3.4.9 >Reporter: Ragul >Priority: Critical > > Version 3.5.4 & 3.4.9 of CXF contains the apache commons-text vulnerable > library (1.9) > [CVE - CVE-2022-42889 > (mitre.org)|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42889] > Fix was available in 1.10.0 commons-text > Is there any plan to upgrade and address this issue? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8777: Assignee: Colm O hEigeartaigh > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8777. -- Resolution: Fixed We have already update commons-text, will be released in 3.5.5 > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8777: - Fix Version/s: 3.5.5 (was: 3.5.4) > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Priority: Major > Fix For: 3.5.5 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8777) cxf-codegen-plugin : 3.5.4 : commons-text :1.9
[ https://issues.apache.org/jira/browse/CXF-8777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624944#comment-17624944 ] Colm O hEigeartaigh commented on CXF-8777: -- Can you give a sample project to reproduce the issue? > cxf-codegen-plugin : 3.5.4 : commons-text :1.9 > -- > > Key: CXF-8777 > URL: https://issues.apache.org/jira/browse/CXF-8777 > Project: CXF > Issue Type: Bug > Components: Build system >Affects Versions: 3.5.4 >Reporter: srinivasarao sanneboyina >Priority: Major > Fix For: 3.5.4 > > > project uses Commons-text package indirectly as shown in below hierarchy with > latest versions. > org.apache.cxf :cxf-codegen-plugin : 3.5.4 (latest) > | > org.apache.cxf : cxf-tools-wsdlto-frontend-jaxws:3.54 (latest) > | > org.apache.cxf: commons-text : 1.9 (removed from maven repo) > > Issue is, exclude of 1.9 does not work as artifact itself does not exist. > Since all older version jar files (till 1.9) are removed for commons-text, > Exclude dependency option for 1.9 is not working. It is trying to pull 1.9 > first before exclude. > Could you please help on the above -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624541#comment-17624541 ] Colm O hEigeartaigh commented on CXF-8776: -- We normally release every 2 months, so mid-December. > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8776. -- Resolution: Fixed > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8776: - Fix Version/s: 3.5.5 > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8776: Assignee: Colm O hEigeartaigh > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.5 > > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8776) Version 3.5.4 contains security vulnerable woodstox version
[ https://issues.apache.org/jira/browse/CXF-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624424#comment-17624424 ] Colm O hEigeartaigh commented on CXF-8776: -- We have already updated to Woodstox 6.4.0 - [https://github.com/apache/cxf/commit/a615cc34ee974469e94c8a0086ec2ed0c84991fa] According to [https://github.com/advisories/GHSA-3f7h-mf4q-vrm4,] it only impacts DTD parsing, which we don't do in CXF. Colm. > Version 3.5.4 contains security vulnerable woodstox version > --- > > Key: CXF-8776 > URL: https://issues.apache.org/jira/browse/CXF-8776 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.4 >Reporter: Shalom Yaish >Priority: Major > > Version 3.5.4 contains the security vulnerable woodstox-core- 6.2.8 > containing this CVE: > CVE-2022-40151 - CVE-2022-40156 > [https://www.mend.io/vulnerability-database/CVE-2022-40151] > The fix existed at woodstox-core-6.4.0 > > Any chance this will be released quickly ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8773) Use https links in website navigation
[ https://issues.apache.org/jira/browse/CXF-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8773. -- Resolution: Fixed Thanks for reporting, it should be fixed now. > Use https links in website navigation > - > > Key: CXF-8773 > URL: https://issues.apache.org/jira/browse/CXF-8773 > Project: CXF > Issue Type: Wish > Components: Documentation >Reporter: Arnout Engelen >Assignee: Colm O hEigeartaigh >Priority: Minor > > Some of the links in the website navigation are still 'http' while they can > be 'https'. This can be updated at > [https://cwiki.apache.org/confluence/display/CXF/Navigation] (but I think I > don't have the necessary permissions). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CXF-8773) Use https links in website navigation
[ https://issues.apache.org/jira/browse/CXF-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8773. > Use https links in website navigation > - > > Key: CXF-8773 > URL: https://issues.apache.org/jira/browse/CXF-8773 > Project: CXF > Issue Type: Wish > Components: Documentation >Reporter: Arnout Engelen >Assignee: Colm O hEigeartaigh >Priority: Minor > > Some of the links in the website navigation are still 'http' while they can > be 'https'. This can be updated at > [https://cwiki.apache.org/confluence/display/CXF/Navigation] (but I think I > don't have the necessary permissions). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CXF-8773) Use https links in website navigation
[ https://issues.apache.org/jira/browse/CXF-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8773: Assignee: Colm O hEigeartaigh > Use https links in website navigation > - > > Key: CXF-8773 > URL: https://issues.apache.org/jira/browse/CXF-8773 > Project: CXF > Issue Type: Wish > Components: Documentation >Reporter: Arnout Engelen >Assignee: Colm O hEigeartaigh >Priority: Minor > > Some of the links in the website navigation are still 'http' while they can > be 'https'. This can be updated at > [https://cwiki.apache.org/confluence/display/CXF/Navigation] (but I think I > don't have the necessary permissions). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CXF-8770) ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl in Java 11 and cxf-bundle:2.7.18
[ https://issues.apache.org/jira/browse/CXF-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXF-8770. Resolution: Won't Fix > ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl > in Java 11 and cxf-bundle:2.7.18 > -- > > Key: CXF-8770 > URL: https://issues.apache.org/jira/browse/CXF-8770 > Project: CXF > Issue Type: Bug > Components: JAX-RS, JAX-WS Runtime, JAXB Databinding >Affects Versions: 3.4.2 >Reporter: Retheesh >Priority: Blocker > > When upgrading Java 8 to 11, I am getting javax.xml dependency not found > error. We are also generating java class from wsdl and xsd, using cxf-codegen > plugin. That classes also uses these dependency. When tried adding the > javax.xml dependency explicitly, the build was success but getting the > following error while we are hitting the service. > {code:java} > unwinding now > java.lang.ClassCastException: class > com.sun.org.apache.xerces.internal.dom.ElementNSImpl cannot be cast to class > javax.xml.soap.SOAPElement > (com.sun.org.apache.xerces.internal.dom.ElementNSImpl is in module java.xml > of loader 'bootstrap'; javax.xml.soap.SOAPElement is in unnamed module of > loader 'app') > at > org.apache.cxf.binding.soap.saaj.SAAJStreamWriter.adjustOverlaidNode(SAAJStreamWriter.java:67) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter.writeStartElement(OverlayW3CDOMStreamWriter.java:188) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:127) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:86) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:66) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) > ~[cxf-bundle-2.7.11.jar:2.7.11] > {code} > I am using cxf-bundle 2.7.18 and cxf-codegen 3.4.2. Also I am using > org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.14.0. > Java version : open-jdk 11.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8770) ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl in Java 11 and cxf-bundle:2.7.18
[ https://issues.apache.org/jira/browse/CXF-8770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17611476#comment-17611476 ] Colm O hEigeartaigh commented on CXF-8770: -- CXF 2.7.18 was released back in 2015, please try with a more recent version. > ClassCastException with com.sun.org.apache.xerces.internal.dom.ElementNSImpl > in Java 11 and cxf-bundle:2.7.18 > -- > > Key: CXF-8770 > URL: https://issues.apache.org/jira/browse/CXF-8770 > Project: CXF > Issue Type: Bug > Components: JAX-RS, JAX-WS Runtime, JAXB Databinding >Affects Versions: 3.4.2 >Reporter: Retheesh >Priority: Blocker > > When upgrading Java 8 to 11, I am getting javax.xml dependency not found > error. We are also generating java class from wsdl and xsd, using cxf-codegen > plugin. That classes also uses these dependency. When tried adding the > javax.xml dependency explicitly, the build was success but getting the > following error while we are hitting the service. > {code:java} > unwinding now > java.lang.ClassCastException: class > com.sun.org.apache.xerces.internal.dom.ElementNSImpl cannot be cast to class > javax.xml.soap.SOAPElement > (com.sun.org.apache.xerces.internal.dom.ElementNSImpl is in module java.xml > of loader 'bootstrap'; javax.xml.soap.SOAPElement is in unnamed module of > loader 'app') > at > org.apache.cxf.binding.soap.saaj.SAAJStreamWriter.adjustOverlaidNode(SAAJStreamWriter.java:67) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.staxutils.OverlayW3CDOMStreamWriter.writeStartElement(OverlayW3CDOMStreamWriter.java:188) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:127) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:86) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:66) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > ~[cxf-bundle-2.7.11.jar:2.7.11] > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) > ~[cxf-bundle-2.7.11.jar:2.7.11] > {code} > I am using cxf-bundle 2.7.18 and cxf-codegen 3.4.2. Also I am using > org.jvnet.jaxb2.maven2:maven-jaxb2-plugin:0.14.0. > Java version : open-jdk 11.0.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CXF-8754) Update to Jetty 10
[ https://issues.apache.org/jira/browse/CXF-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8754. -- Resolution: Duplicate > Update to Jetty 10 > -- > > Key: CXF-8754 > URL: https://issues.apache.org/jira/browse/CXF-8754 > Project: CXF > Issue Type: Improvement >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8749) Existing handler file fails the compile generated java source files
[ https://issues.apache.org/jira/browse/CXF-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610987#comment-17610987 ] Colm O hEigeartaigh commented on CXF-8749: -- [~ema] Can the Jira be closed? Are all fixes backported to 3.5.x-fixes? > Existing handler file fails the compile generated java source files > --- > > Key: CXF-8749 > URL: https://issues.apache.org/jira/browse/CXF-8749 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 3.5.3 >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 4.0.0, 3.5.4 > > > Use wsdl2java to generate code for two wsdls , and passing the same "-d" and > "-classdir" flags to put the source files and compiled classes to one > directory. The first wsdl file generated handler files always fails compiler > the source files by the second wsdl. > {code:java} > org.apache.cxf.tools.common.ToolException: > FAIL_TO_COPY_GENERATED_RESOURCE_FILE > at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:104) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:295) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:156) > at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:402) > at > org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105) > at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) > at > org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:303) > at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298) > at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108) > at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96) > Caused by: java.nio.file.FileAlreadyExistsException: > /Users/jimma/classes/generated-classes/Endpoint_handler.xml > at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:551) > at > sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253) > at java.nio.file.Files.copy(Files.java:1274) > at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:99) > ... 9 more{code} > > This issue is introduced by: > {code:java} > commit f5f08c838e1d52f17bcc8422fac38831a63e6e30 > Author: Alexey Markevich > Date: Mon Nov 16 10:44:36 2020 +0300 > cxf-tools-common: use Files.copy > {code} > [https://github.com/apache/cxf/commit/f5f08c838e1d52f17bcc8422fac38831a63e6e30] > > It's better to add a warning message instead of throwing exception which > fails the compiling generated files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CXF-8712) RetryStrategy tries one time too often
[ https://issues.apache.org/jira/browse/CXF-8712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8712: - Fix Version/s: (was: 4.0.0) (was: 3.6.0) (was: 3.5.4) (was: 3.4.9) > RetryStrategy tries one time too often > -- > > Key: CXF-8712 > URL: https://issues.apache.org/jira/browse/CXF-8712 > Project: CXF > Issue Type: Bug > Components: Clustering >Affects Versions: 3.4.7 >Reporter: Konrad Windszus >Priority: Major > > The maxNumberOfRetries is not correctly evaluated in the RetryStrategy. If it > is set to 3, the amount of retries is actually 4. > This is due to the fact that {{getNextAlternate()}} will return the same > result for both {{stillTheSameAddress}} returning either {{false}} or > {{true}}. > Although the break condition in > https://github.com/apache/cxf/blob/75fb6bb56d82f72771a9ee6ecab5d36168303f51/rt/features/clustering/src/main/java/org/apache/cxf/clustering/RetryStrategy.java#L55 > is correct, the logic in > https://github.com/apache/cxf/blob/75fb6bb56d82f72771a9ee6ecab5d36168303f51/rt/features/clustering/src/main/java/org/apache/cxf/clustering/RetryStrategy.java#L45 > is flawed, as it will not return the next alternate in case > {{stillTheSameAddress}} returns false. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8737) XSDs imported in wsdl has schema location starting with http even though wsdl is accessible over htts url
[ https://issues.apache.org/jira/browse/CXF-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597694#comment-17597694 ] Colm O hEigeartaigh commented on CXF-8737: -- Can you create a test-case that reproduces the problem? > XSDs imported in wsdl has schema location starting with http even though wsdl > is accessible over htts url > - > > Key: CXF-8737 > URL: https://issues.apache.org/jira/browse/CXF-8737 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Reporter: Amit Anand >Priority: Major > > XSDs imported in wsdl has schema location starting with http even though wsdl > is accessible over htts url > > Wsdl url: https: url-Mapping>//?wsdl > xsd url: http: url-Mapping>//?xsd=.xsd > xsd is imported in wsdl with a namespace and relative schemaLocation. > Deployed as Spring Boot application with CXF servlet bean registration and > jaxws endpoint -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8745) MemoryLeak when using SpringBus in a spring context which has a reusable parent context
[ https://issues.apache.org/jira/browse/CXF-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597639#comment-17597639 ] Colm O hEigeartaigh commented on CXF-8745: -- Hi, can you consider opening a pull request for this issue? > MemoryLeak when using SpringBus in a spring context which has a reusable > parent context > --- > > Key: CXF-8745 > URL: https://issues.apache.org/jira/browse/CXF-8745 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 3.5.3 >Reporter: Eric >Priority: Minor > > SpringBus automatically registers itself as an ApplicationListener in the > SpringContext and recursively also in all its parents: > > {code:java} > public void setApplicationContext(ApplicationContext applicationContext) { > ctx = (AbstractApplicationContext)applicationContext; > @SuppressWarnings("rawtypes") > ApplicationListener listener = new ApplicationListener() { > public void onApplicationEvent(ApplicationEvent event) { > SpringBus.this.onApplicationEvent(event); > } > }; > ctx.addApplicationListener(listener); > ApplicationContext ac = applicationContext.getParent(); > while (ac != null) { > if (ac instanceof AbstractApplicationContext) { > > ((AbstractApplicationContext)ac).addApplicationListener(listener); > } > ac = ac.getParent(); > } > }{code} > This leads to a MemoryLeak when the current SpringContext is closed but the > ParentContext is reused for another child context, because the > ApplicationListener references the SpringBus and the SpringBus references the > old ApplicationContext. > > A very simple approach to solve this problem would be to deregister the > listener in a destroy-block or to just use a WeakReference. The later is also > used by spring itself when they register a listener in the parent to > automatically close all related child contexts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8708) org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR when requesting a WSFED security token
[ https://issues.apache.org/jira/browse/CXF-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17555438#comment-17555438 ] Colm O hEigeartaigh commented on CXF-8708: -- Is there a way to create a test-case to reproduce the problem? > org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR when requesting a WSFED security > token > --- > > Key: CXF-8708 > URL: https://issues.apache.org/jira/browse/CXF-8708 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 3.4.4 > Environment: Windows Server 2019 datacenter > > openjdk version "1.8.0_322" > OpenJDK Runtime Environment (build 1.8.0_322-b06) > OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode) > > JBoss EAP 7.3.10.GA (WildFly Core 10.1.25.Final-redhat-1) >Reporter: David Leruse >Priority: Blocker > Attachments: STSCustomClient.java > > > Migrating a project from cxf 3.0.3 (on java 7 with jboss 6.3.3 ) to cxf 3.4.4 > (on java 8 with jboss 7.3.10 ), i've now the following issue when trying to > request a security token from an identical ADFS. > > Could you please advice ? > > David L. > 2022-06-01 13:27:07,415 ERROR [org.riziv.wsfed.STSCustomClient] (default > task-5) an error has occurred in the STSCustomClient connectWithUser method: > org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different > document than the one that created it. > at > com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(ParentNode.java:356) > at > com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(ParentNode.java:287) > at > org.apache.wss4j.dom.util.WSSecurityUtil.prependChildElement(WSSecurityUtil.java:370) > at > org.apache.wss4j.dom.util.WSSecurityUtil.findWsseSecurityHeaderBlock(WSSecurityUtil.java:490) > at > org.apache.wss4j.dom.message.WSSecHeader.insertSecurityHeader(WSSecHeader.java:167) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessageInternal(PolicyBasedWSS4JOutInterceptor.java:145) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:110) > at > org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:97) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) > at > org.apache.cxf.ws.security.trust.AbstractSTSClient.issue(AbstractSTSClient.java:874) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:71) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:65) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:61) > at org.riziv.wsfed.STSCustomClient.connectWithUser(Unknown Source) > at org.riziv.wsfed.STSCustomClient.requestSecurityToken(Unknown Source) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:65) > at > org.apache.cxf.ws.security.trust.STSClient.requestSecurityToken(STSClient.java:61) > at > org.apache.cxf.ws.security.trust.STSTokenRetriever.getTokenFromSTS(STSTokenRetriever.java:267) > at > org.apache.cxf.ws.security.trust.STSTokenRetriever.getToken(STSTokenRetriever.java:111) > at > org.apache.cxf.ws.security.policy.interceptors.IssuedTokenInterceptorProvider$IssuedTokenOutInterceptor.handleMessage(IssuedTokenInterceptorProvider.java:147) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140) > at com.sun.proxy.$Proxy203.searchOrganisation(Unknown Source) > at > com.eistream.sonora.grammar.extended.OpDoContactConsultationSearchOrganisation.doRequest(Unknown > Source) > at > com.eistream.sonora.grammar.extended.OpDoContactConsultationSearchOrganisation.doRequest(Unknown > Source) >
[jira] [Resolved] (CXF-8705) Multiple encrypted XML elements fail crypto coverage check
[ https://issues.apache.org/jira/browse/CXF-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8705. -- Resolution: Cannot Reproduce Feel free to re-open if you can answer the questions in the comment. > Multiple encrypted XML elements fail crypto coverage check > -- > > Key: CXF-8705 > URL: https://issues.apache.org/jira/browse/CXF-8705 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.5.2 > Environment: * Apache Maven 3.8.5 > * Java version: 11.0.12, vendor: Eclipse Foundation > * Apache Tomcat 9.0.62 > * openSUSE Tumbleweed 20220509 >Reporter: David Lakatos >Priority: Major > > Hello colleagues, > I probably found a bug in > {{org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker}}. > * Issue: SOAP XML message encryption coverage checking for more than 1 XML > elements does not work. If only 1 XML element encryption coverage is checked, > everything works fine. > * Symptoms: [CryptoCoverageUtil.matchElement(Collection, > CoverageScope, > Element)|https://github.com/apache/cxf/blob/cxf-3.5.2/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/CryptoCoverageUtil.java#L381] > compares objects via references ({{r.getProtectedElement() == el}}) but they > are always different objects > * Reproducer JUnit tests are provided on GitHub: > [greatit/crypto-coverage-test|https://github.com/greatit/crypto-coverage-test] > Fixing the issue would be much appreciated. Thank you. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (CXFXJC-41) Regression with JAXB 2.3.5 / 3.x: "http://schemas.xmlsoap.org/wsdl/" is not a part of this compilation
[ https://issues.apache.org/jira/browse/CXFXJC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXFXJC-41. - > Regression with JAXB 2.3.5 / 3.x: "http://schemas.xmlsoap.org/wsdl/"; is not a > part of this compilation > -- > > Key: CXFXJC-41 > URL: https://issues.apache.org/jira/browse/CXFXJC-41 > Project: CXF XJC Utils > Issue Type: Bug >Affects Versions: 3.3.1 >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0, 3.3.2 > > > Interesting regression has been observed with JAXB 2.3.5 and 3.x: the CXF > builds are failing with : > > {noformat} > [ERROR] rt\wsdl\src\test\resources\schemas\wsdl\test-conf.xjb [25:88]: > "http://schemas.xmlsoap.org/wsdl/"; is not a part of this compilation. Is this > a mistake for "file:core/src/main/resources/schemas/wsdl/wsdl.xsd"? > > com.sun.istack.SAXParseException2; systemId: > file:/rt/wsdl/src/test/resources/schemas/wsdl/test-conf.xjb; lineNumber: 25; > columnNumber: 88; "http://schemas.xmlsoap.org/wsdl/"; is not a part of this > compilation. Is this a mistake for > "file:core/src/main/resources/schemas/wsdl/wsdl.xsd"? > at > com.sun.tools.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:570) > > > at > com.sun.tools.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:563) > > > at > com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:206) > > > at > com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:335) > > > at > com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:116) > > > at > com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:77) > > > at > com.sun.tools.xjc.reader.internalizer.DOMForest.transform(DOMForest.java:429) > > > at com.sun.tools.xjc.ModelLoader.buildDOMForest(ModelLoader.java:286) > > > at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:318) > > > at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:121) > > > at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:76) > > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > > > at > org.apache.cxf.maven_plugin.XSDToJavaRunner.loadModel(XSDToJavaRunner.java:224) > > > at > org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:174) >
[jira] [Closed] (CXFXJC-40) Support Jakarta EE 9.0+
[ https://issues.apache.org/jira/browse/CXFXJC-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed CXFXJC-40. - > Support Jakarta EE 9.0+ > --- > > Key: CXFXJC-40 > URL: https://issues.apache.org/jira/browse/CXFXJC-40 > Project: CXF XJC Utils > Issue Type: New Feature >Reporter: Andriy Redko >Assignee: Andriy Redko >Priority: Major > Fix For: 4.0.0 > > > The `xjc-utils` use the `javax` artifacts for code generation, it would make > sense to branch off 4.0.0 to support Jakarka artifacts and align with CXF > plans to support Jakarta as well. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (CXF-8567) AdviceBean in CXF STS using SAMLTokenProvider
[ https://issues.apache.org/jira/browse/CXF-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8567: Assignee: Colm O hEigeartaigh > AdviceBean in CXF STS using SAMLTokenProvider > - > > Key: CXF-8567 > URL: https://issues.apache.org/jira/browse/CXF-8567 > Project: CXF > Issue Type: New Feature > Components: JAX-WS Runtime, STS >Affects Versions: 3.4.4 >Reporter: subigre >Assignee: Colm O hEigeartaigh >Priority: Major > > In the context of a new project, I need to implement a STS that generates > some SAML tokens for users already authenticated. > As a result, the SAML assertion returns by the STS must contain reference to > the SAML assertion sent in the request. > > {code:java} > IssueInstant="2021-07-22T21:02:16.176Z" Version="2.0" > xsi:type="saml2:AssertionType" > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > ... > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">fPzBicjKXtADawasyp1d1w== > Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/> > > NotOnOrAfter="2021-07-13T14:07:58.417Z"/> > > > _2c84dd7b-728c-4a35-95ed-dc36aeda731e > > > > > urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession > > > ... > > {code} > > Currently, I implement my own providers using the following interfaces to > populate/customize the rest of the SAML assertion: > * {{AttributeStatementProvider}} > * {{AuthDecisionStatementProvider}} > * {{AuthenticationStatementProvider}} > * {{ConditionsProvider}} > However, I do not find a mechanism to populate the {{AdviceBean.}} > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CXF-8705) Multiple encrypted XML elements fail crypto coverage check
[ https://issues.apache.org/jira/browse/CXF-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17543938#comment-17543938 ] Colm O hEigeartaigh commented on CXF-8705: -- Hi, How can I run the tests - does it require the server to be running somehow? Are you checking that you aren't signing the encrypted values on the outbound side? > Multiple encrypted XML elements fail crypto coverage check > -- > > Key: CXF-8705 > URL: https://issues.apache.org/jira/browse/CXF-8705 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.5.2 > Environment: * Apache Maven 3.8.5 > * Java version: 11.0.12, vendor: Eclipse Foundation > * Apache Tomcat 9.0.62 > * openSUSE Tumbleweed 20220509 >Reporter: David Lakatos >Priority: Major > > Hello colleagues, > I probably found a bug in > {{org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker}}. > * Issue: SOAP XML message encryption coverage checking for more than 1 XML > elements does not work. If only 1 XML element encryption coverage is checked, > everything works fine. > * Symptoms: [CryptoCoverageUtil.matchElement(Collection, > CoverageScope, > Element)|https://github.com/apache/cxf/blob/cxf-3.5.2/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/CryptoCoverageUtil.java#L381] > compares objects via references ({{r.getProtectedElement() == el}}) but they > are always different objects > * Reproducer JUnit tests are provided on GitHub: > [greatit/crypto-coverage-test|https://github.com/greatit/crypto-coverage-test] > Fixing the issue would be much appreciated. Thank you. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[ https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541318#comment-17541318 ] Colm O hEigeartaigh commented on CXFXJC-42: --- 3.3.2 is now available on Maven Central. > cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc > dependency > --- > > Key: CXFXJC-42 > URL: https://issues.apache.org/jira/browse/CXFXJC-42 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.1 > Environment: Windows 10 > Java 17.0.3 (Bellsoft Liberica) >Reporter: Falko Modler >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.2 > > > Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after > updating from Java 17.0.2 to 17.0.3: > {noformat} > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.772 s (Wall Clock) > [INFO] Finished at: 2022-04-26T17:28:54+02:00 > [INFO] > > [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava > (xjc) on project register-something: > [ERROR] Exit code: 1 > [ERROR] Command line was: > C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe > --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED > --add-opens java.base/java.security=ALL-UNNAMED --add-opens > java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED > --add-opens java.base/java.util=ALL-UNNAMED --add-opens > java.base/java.util.concurrent=ALL-UNNAMED -jar > C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar > -b > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb > -extension -Xannotate -encoding UTF-8 -d > C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/ > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd > [ERROR] > {noformat} > {{mvn -X}} reveals: > {noformat} > [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException: > "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar" > ist kein gültiger Dateiname: {1} > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515) > [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360) > [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path > [DEBUG] at java.base/java.io.File.toURL(File.java:695) > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512) > {noformat} > ("ist kein gültiger Dateiname:" is something like "is not a valid file name") > This config is triggering the issue: > {code:xml} > > > > org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version} > > > {code} > Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the > plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x). > Ironically, that update was done already a year ago via > https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49 > but there hasn't been a release since then. > PS: Latest {{cxf-codegen-
[jira] [Updated] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[ https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXFXJC-42: -- Fix Version/s: 3.3.2 > cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc > dependency > --- > > Key: CXFXJC-42 > URL: https://issues.apache.org/jira/browse/CXFXJC-42 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.1 > Environment: Windows 10 > Java 17.0.3 (Bellsoft Liberica) >Reporter: Falko Modler >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.2 > > > Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after > updating from Java 17.0.2 to 17.0.3: > {noformat} > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.772 s (Wall Clock) > [INFO] Finished at: 2022-04-26T17:28:54+02:00 > [INFO] > > [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava > (xjc) on project register-something: > [ERROR] Exit code: 1 > [ERROR] Command line was: > C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe > --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED > --add-opens java.base/java.security=ALL-UNNAMED --add-opens > java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED > --add-opens java.base/java.util=ALL-UNNAMED --add-opens > java.base/java.util.concurrent=ALL-UNNAMED -jar > C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar > -b > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb > -extension -Xannotate -encoding UTF-8 -d > C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/ > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd > [ERROR] > {noformat} > {{mvn -X}} reveals: > {noformat} > [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException: > "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar" > ist kein gültiger Dateiname: {1} > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515) > [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360) > [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path > [DEBUG] at java.base/java.io.File.toURL(File.java:695) > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512) > {noformat} > ("ist kein gültiger Dateiname:" is something like "is not a valid file name") > This config is triggering the issue: > {code:xml} > > > > org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version} > > > {code} > Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the > plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x). > Ironically, that update was done already a year ago via > https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49 > but there hasn't been a release since then. > PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}. -- This message was
[jira] [Resolved] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[ https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXFXJC-42. --- Resolution: Fixed > cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc > dependency > --- > > Key: CXFXJC-42 > URL: https://issues.apache.org/jira/browse/CXFXJC-42 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.1 > Environment: Windows 10 > Java 17.0.3 (Bellsoft Liberica) >Reporter: Falko Modler >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.3.2 > > > Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after > updating from Java 17.0.2 to 17.0.3: > {noformat} > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.772 s (Wall Clock) > [INFO] Finished at: 2022-04-26T17:28:54+02:00 > [INFO] > > [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava > (xjc) on project register-something: > [ERROR] Exit code: 1 > [ERROR] Command line was: > C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe > --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED > --add-opens java.base/java.security=ALL-UNNAMED --add-opens > java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED > --add-opens java.base/java.util=ALL-UNNAMED --add-opens > java.base/java.util.concurrent=ALL-UNNAMED -jar > C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar > -b > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb > -extension -Xannotate -encoding UTF-8 -d > C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/ > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd > [ERROR] > {noformat} > {{mvn -X}} reveals: > {noformat} > [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException: > "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar" > ist kein gültiger Dateiname: {1} > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515) > [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360) > [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path > [DEBUG] at java.base/java.io.File.toURL(File.java:695) > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512) > {noformat} > ("ist kein gültiger Dateiname:" is something like "is not a valid file name") > This config is triggering the issue: > {code:xml} > > > > org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version} > > > {code} > Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the > plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x). > Ironically, that update was done already a year ago via > https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49 > but there hasn't been a release since then. > PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}. -- This message was s
[jira] [Assigned] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[ https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXFXJC-42: - Assignee: Colm O hEigeartaigh > cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc > dependency > --- > > Key: CXFXJC-42 > URL: https://issues.apache.org/jira/browse/CXFXJC-42 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.1 > Environment: Windows 10 > Java 17.0.3 (Bellsoft Liberica) >Reporter: Falko Modler >Assignee: Colm O hEigeartaigh >Priority: Major > > Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after > updating from Java 17.0.2 to 17.0.3: > {noformat} > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.772 s (Wall Clock) > [INFO] Finished at: 2022-04-26T17:28:54+02:00 > [INFO] > > [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava > (xjc) on project register-something: > [ERROR] Exit code: 1 > [ERROR] Command line was: > C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe > --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED > --add-opens java.base/java.security=ALL-UNNAMED --add-opens > java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED > --add-opens java.base/java.util=ALL-UNNAMED --add-opens > java.base/java.util.concurrent=ALL-UNNAMED -jar > C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar > -b > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb > -extension -Xannotate -encoding UTF-8 -d > C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/ > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd > [ERROR] > {noformat} > {{mvn -X}} reveals: > {noformat} > [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException: > "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar" > ist kein gültiger Dateiname: {1} > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515) > [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360) > [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path > [DEBUG] at java.base/java.io.File.toURL(File.java:695) > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512) > {noformat} > ("ist kein gültiger Dateiname:" is something like "is not a valid file name") > This config is triggering the issue: > {code:xml} > > > > org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version} > > > {code} > Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the > plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x). > Ironically, that update was done already a year ago via > https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49 > but there hasn't been a release since then. > PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}. -- This message was sent by Atlassi
[jira] [Commented] (CXF-8699) Abillity to set sensitive filters on LoggingFeature
[ https://issues.apache.org/jira/browse/CXF-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17536510#comment-17536510 ] Colm O hEigeartaigh commented on CXF-8699: -- Hi [~jgreffe] , Yes please just submit a new PR for it. We can use the same JIRA. > Abillity to set sensitive filters on LoggingFeature > --- > > Key: CXF-8699 > URL: https://issues.apache.org/jira/browse/CXF-8699 > Project: CXF > Issue Type: Improvement > Components: logging >Affects Versions: 3.4.7 >Reporter: Julien Greffe >Priority: Major > Fix For: 4.0.0, 3.6.0, 3.5.3, 3.4.8 > > > Hello, > class {{LoggingFeature}} has new methods to add sensitive filters on custom > LoggingFeature: > {code} > addSensitiveElementNames > addSensitiveProtocolHeaderNames > {code} > Currently, we can't configure the default LoggingFeature to filter sensitive > informations from scratch through configuration. > More, we can't change configuration to update filters and have them reflected > on default LoggingFeature. > Idea is to: > - add two methods > {code} > setSensitiveElementNames > setSensitiveProtocolHeaderNames > {code} > - add two configuration keys: > {code} > sensitiveElementNames > sensitiveProtocolHeaderNames > {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CXFXJC-42) cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc dependency
[ https://issues.apache.org/jira/browse/CXFXJC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534167#comment-17534167 ] Colm O hEigeartaigh commented on CXFXJC-42: --- [~reta] Yes, no problem for me. > cxf-xjc-plugin fails with Java 17.0.3 on Windows due to outdated xjc > dependency > --- > > Key: CXFXJC-42 > URL: https://issues.apache.org/jira/browse/CXFXJC-42 > Project: CXF XJC Utils > Issue Type: Bug > Components: Maven Plugin >Affects Versions: 3.3.1 > Environment: Windows 10 > Java 17.0.3 (Bellsoft Liberica) >Reporter: Falko Modler >Priority: Major > > Latest 3.3.1 of the plugin started to fail on Windows (not on Linux!) after > updating from Java 17.0.2 to 17.0.3: > {noformat} > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.772 s (Wall Clock) > [INFO] Finished at: 2022-04-26T17:28:54+02:00 > [INFO] > > [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:3.3.1:xsdtojava > (xjc) on project register-something: > [ERROR] Exit code: 1 > [ERROR] Command line was: > C:\Users\foo\.sdkman\candidates\java\17.0.3-librca\bin\java.exe > --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED > --add-opens java.base/java.security=ALL-UNNAMED --add-opens > java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED > --add-opens java.base/java.util=ALL-UNNAMED --add-opens > java.base/java.util.concurrent=ALL-UNNAMED -jar > C:\Develop\Temp\cxf-xjc-plugin11678367863192748736.jar -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-tools/0.12.0/jaxb2-basics-tools-0.12.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/annox/annox/1.0.2/annox-1.0.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/apache/commons/commons-lang3/3.2.1/commons-lang3-3.2.1.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/jcl-over-slf4j/1.7.7/jcl-over-slf4j-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/jvnet/jaxb2_commons/jaxb2-basics-annotate/1.1.0/jaxb2-basics-annotate-1.1.0.jar > -classpath > file:/C:/Users/foo/.m2/repository/com/google/code/javaparser/javaparser/1.0.11/javaparser-1.0.11.jar > -classpath > file:/C:/Users/foo/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar > -classpath > file:/C:/Users/foo/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar > -b > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xjc-bindings.xjb > -extension -Xannotate -encoding UTF-8 -d > C:\Develop\project\dev2\register.git\something\target/generated-sources/xsd/ > file:/C:/Develop/project/dev2/register.git/something/src/main/resources/webservice/xml-data-1.0.xsd > [ERROR] > {noformat} > {{mvn -X}} reveals: > {noformat} > [DEBUG] Exception in thread "main" com.sun.tools.xjc.BadCommandLineException: > "file:\C:\Users\foo\.m2\repository\org\jvnet\jaxb2_commons\jaxb2-basics-tools\0.12.0\jaxb2-basics-tools-0.12.0.jar" > ist kein gültiger Dateiname: {1} > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:515) > [DEBUG] at com.sun.tools.xjc.Options.parseArguments(Options.java:827) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:170) > [DEBUG] at > org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360) > [DEBUG] Caused by: java.net.MalformedURLException: Invalid file path > [DEBUG] at java.base/java.io.File.toURL(File.java:695) > [DEBUG] at com.sun.tools.xjc.Options.parseArgument(Options.java:512) > {noformat} > ("ist kein gültiger Dateiname:" is something like "is not a valid file name") > This config is triggering the issue: > {code:xml} > > > > org.jvnet.jaxb2_commons:jaxb2-basics-annotate:${jaxb2-basics-annotate.version} > > > {code} > Turns out that updating {{jaxb-xjc}} and {{jaxb-runtime}} dependencies of the > plugin to 2.3.3 or newer fixes the issue (2.3.6 is latest 2.3.x). > Ironically, that update was done already a year ago via > https://github.com/apache/cxf-xjc-utils/commit/5d8724057f1298816573ab59f2100356a7d669d0#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R49 > but there hasn't been a release since then. > PS: Latest {{cxf-codegen-plugin}} 3.5.2 is using 2.3.5 of {{jaxb-runtime}}. -- This message was sent by A
[jira] [Commented] (CXF-8696) Improve build performance of modules
[ https://issues.apache.org/jira/browse/CXF-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528181#comment-17528181 ] Colm O hEigeartaigh commented on CXF-8696: -- Hi, from what I can see the frontend jaxrs module still needs the aegis module as a test dependency? {code:java} [ERROR] /Users/coheigea/src/apache/cxf/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/resources/Tags.java:[27,39] package org.apache.cxf.aegis.type.java5 does not exist [ERROR] /Users/coheigea/src/apache/cxf/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/resources/Tags.java:[45,6] cannot find symbol [ERROR] symbol: class XmlFlattenedArray [ERROR] location: class org.apache.cxf.jaxrs.resources.Tags [ERROR] -> [Help 1] {code} > Improve build performance of modules > > > Key: CXF-8696 > URL: https://issues.apache.org/jira/browse/CXF-8696 > Project: CXF > Issue Type: Improvement > Components: Build system >Affects Versions: 4.0.0 >Reporter: Bing-ok >Priority: Major > > Hi, I'm now using {*}cxf{*}. I found that the build time of the project is > not very fast when I used *mvn -T 1C install -DskipTests* command to build > the project during Github Actions. So I try to speed up the build performance > of the project. The goal here is to clean up dependencies between maven > modules in the project in order to improve the build performance. > Using *mvn dependency:analyze* command I managed to have an overview of the > unused dependencies of every module. I focused only on the dependencies > between modules. The following dependencies can be cleaned up: > {noformat} > org.apache.cxf:cxf-rt-frontend-jaxrs(cxf\rt\frontend\jaxrs) -> > org.apache.cxf:cxf-rt-databinding-aegis(cxf\rt\databinding\aegis){noformat} > After clean up, the build time has been reduced by 3 minutes when I use > parallel build during Github Actions. > Could you help me review this issue? I can submit a PR to improve build > performance of the project. > Thank you very much for your attention. > Best regards. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (CXF-8579) Upgrade wss4j to v3.0.0 and OpenSAML to 4.x
[ https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8579. -- Resolution: Fixed > Upgrade wss4j to v3.0.0 and OpenSAML to 4.x > --- > > Key: CXF-8579 > URL: https://issues.apache.org/jira/browse/CXF-8579 > Project: CXF > Issue Type: Task > Components: STS, WS-* Components >Affects Versions: 3.5.0 >Reporter: Misagh Moayyed >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.0 > > > The next release of wss4j has switched to support OpenSAML v4. This release > as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it > turns out that SAMLTokenProvider is not compatible with the latest wss4j and > opensaml v4, mainly due to the following: > > {code:java} > DateTime validFrom = null; > DateTime validTill = null; > if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) { > validFrom = assertion.getSaml2().getConditions().getNotBefore(); > validTill = assertion.getSaml2().getConditions().getNotOnOrAfter(); > } else { > validFrom = assertion.getSaml1().getConditions().getNotBefore(); > validTill = assertion.getSaml1().getConditions().getNotOnOrAfter(); > } > {code} > There may be other areas that require attention. > This Jira focuses on upgrading wss4j to the next 2.5.x line, while making > sure opensaml v4 continues to work correctly. If possible, it would be great > to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT > version for wss4j, and allow the user community to test it. > > I can surely submit a patch or pull request that attempts to handle the > upgrade on GH, etc. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8579) Upgrade wss4j to v3.0.0 and OpenSAML to 4.x
[ https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8579: - Summary: Upgrade wss4j to v3.0.0 and OpenSAML to 4.x (was: Upgrade wss4j to v2.5.0 and OpenSAML to 4.x) > Upgrade wss4j to v3.0.0 and OpenSAML to 4.x > --- > > Key: CXF-8579 > URL: https://issues.apache.org/jira/browse/CXF-8579 > Project: CXF > Issue Type: Task > Components: STS, WS-* Components >Affects Versions: 3.5.0 >Reporter: Misagh Moayyed >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.0 > > > The next release of wss4j has switched to support OpenSAML v4. This release > as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it > turns out that SAMLTokenProvider is not compatible with the latest wss4j and > opensaml v4, mainly due to the following: > > {code:java} > DateTime validFrom = null; > DateTime validTill = null; > if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) { > validFrom = assertion.getSaml2().getConditions().getNotBefore(); > validTill = assertion.getSaml2().getConditions().getNotOnOrAfter(); > } else { > validFrom = assertion.getSaml1().getConditions().getNotBefore(); > validTill = assertion.getSaml1().getConditions().getNotOnOrAfter(); > } > {code} > There may be other areas that require attention. > This Jira focuses on upgrading wss4j to the next 2.5.x line, while making > sure opensaml v4 continues to work correctly. If possible, it would be great > to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT > version for wss4j, and allow the user community to test it. > > I can surely submit a patch or pull request that attempts to handle the > upgrade on GH, etc. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8579) Upgrade wss4j to v2.5.0 and OpenSAML to 4.x
[ https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8579: - Fix Version/s: 4.0.0 > Upgrade wss4j to v2.5.0 and OpenSAML to 4.x > --- > > Key: CXF-8579 > URL: https://issues.apache.org/jira/browse/CXF-8579 > Project: CXF > Issue Type: Task > Components: STS, WS-* Components >Affects Versions: 3.5.0 >Reporter: Misagh Moayyed >Priority: Minor > Fix For: 4.0.0 > > > The next release of wss4j has switched to support OpenSAML v4. This release > as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it > turns out that SAMLTokenProvider is not compatible with the latest wss4j and > opensaml v4, mainly due to the following: > > {code:java} > DateTime validFrom = null; > DateTime validTill = null; > if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) { > validFrom = assertion.getSaml2().getConditions().getNotBefore(); > validTill = assertion.getSaml2().getConditions().getNotOnOrAfter(); > } else { > validFrom = assertion.getSaml1().getConditions().getNotBefore(); > validTill = assertion.getSaml1().getConditions().getNotOnOrAfter(); > } > {code} > There may be other areas that require attention. > This Jira focuses on upgrading wss4j to the next 2.5.x line, while making > sure opensaml v4 continues to work correctly. If possible, it would be great > to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT > version for wss4j, and allow the user community to test it. > > I can surely submit a patch or pull request that attempts to handle the > upgrade on GH, etc. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CXF-8579) Upgrade wss4j to v2.5.0 and OpenSAML to 4.x
[ https://issues.apache.org/jira/browse/CXF-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-8579: Assignee: Colm O hEigeartaigh > Upgrade wss4j to v2.5.0 and OpenSAML to 4.x > --- > > Key: CXF-8579 > URL: https://issues.apache.org/jira/browse/CXF-8579 > Project: CXF > Issue Type: Task > Components: STS, WS-* Components >Affects Versions: 3.5.0 >Reporter: Misagh Moayyed >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 4.0.0 > > > The next release of wss4j has switched to support OpenSAML v4. This release > as of this writing is in SNAPSHOT mode. When testing wss4j against CXF, it > turns out that SAMLTokenProvider is not compatible with the latest wss4j and > opensaml v4, mainly due to the following: > > {code:java} > DateTime validFrom = null; > DateTime validTill = null; > if (assertion.getSamlVersion().equals(SAMLVersion.VERSION_20)) { > validFrom = assertion.getSaml2().getConditions().getNotBefore(); > validTill = assertion.getSaml2().getConditions().getNotOnOrAfter(); > } else { > validFrom = assertion.getSaml1().getConditions().getNotBefore(); > validTill = assertion.getSaml1().getConditions().getNotOnOrAfter(); > } > {code} > There may be other areas that require attention. > This Jira focuses on upgrading wss4j to the next 2.5.x line, while making > sure opensaml v4 continues to work correctly. If possible, it would be great > to publish a SNAPSHOT version of CXF that contains an updated 2.5.0-SNAPSHOT > version for wss4j, and allow the user community to test it. > > I can surely submit a patch or pull request that attempts to handle the > upgrade on GH, etc. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8687) Version 3.4.6 contains vulnerable spring version
[ https://issues.apache.org/jira/browse/CXF-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520933#comment-17520933 ] Colm O hEigeartaigh commented on CXF-8687: -- [https://repo1.maven.org/maven2/org/apache/cxf/apache-cxf/3.4.7/] > Version 3.4.6 contains vulnerable spring version > > > Key: CXF-8687 > URL: https://issues.apache.org/jira/browse/CXF-8687 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.4.6 >Reporter: Mathieu Veurman >Priority: Critical > > Version 3.4.6 contains the vulnerable spring core version 5.2.19, containing > this CVE: > CVE-2022-22965: Spring Framework RCE via Data Binding on JDK 9+ > > I do see this commit where the proper version of spring is referenced: > [https://github.com/apache/cxf/commit/0f8b5a2c2a66ab62c931096aaf512390d58fef3d] > > Any chance this will be released quickly as 3.4.7? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8686) JWT role claim incorrectly parsed if not tokenized as string
[ https://issues.apache.org/jira/browse/CXF-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8686. -- Resolution: Fixed > JWT role claim incorrectly parsed if not tokenized as string > > > Key: CXF-8686 > URL: https://issues.apache.org/jira/browse/CXF-8686 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.4.6, 3.5.1 >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.5.2, 4.0.0 > > Attachments: image-2022-04-05-14-08-09-726.png > > > The JwtTokenSecurityContext class expects a tokenized string for the role > claim. If the JWT contains an array of strings to represent the roles the > role claim is incorrectly parsed. > The following line shows that it always first tokenize the array: > [https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/JwtTokenSecurityContext.java#L48] > Here is a snippet of the sample JWT: > > {\{{}} > {{ "sub": "myid",}} > {{ "jti": "f42150ef-2743-4ca0-ae06-a23b307edaca",}} > {{ "iss": "STS INT",}} > {{ "roles": [}} > {{ "READ",}} > {{ "UPDATE"}} > {{ ],}} > {{ "iat": 1649079679,}} > {{ "nbf": 1649079679,}} > {{ "exp": 1649086879,}} > {{ "aud": [}} > {{ "urn:mycompany:application:foo"}} > {{ ]}} > {{}}} > > I propose to improve this logic thus both roles in tokenized string as well > as a propery array list are properly parsed. > > Here a snippet of the debugger. The above example ends-up with two roles > "[READ" and " UPDATE]". > > !image-2022-04-05-14-08-09-726.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8686) JWT role claim incorrectly parsed if not tokenized as string
[ https://issues.apache.org/jira/browse/CXF-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8686: - Fix Version/s: 3.5.2 (was: 3.5.3) > JWT role claim incorrectly parsed if not tokenized as string > > > Key: CXF-8686 > URL: https://issues.apache.org/jira/browse/CXF-8686 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.4.6, 3.5.1 >Reporter: Oliver Wulff >Priority: Major > Fix For: 3.5.2, 4.0.0 > > Attachments: image-2022-04-05-14-08-09-726.png > > > The JwtTokenSecurityContext class expects a tokenized string for the role > claim. If the JWT contains an array of strings to represent the roles the > role claim is incorrectly parsed. > The following line shows that it always first tokenize the array: > [https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/JwtTokenSecurityContext.java#L48] > Here is a snippet of the sample JWT: > > {\{{}} > {{ "sub": "myid",}} > {{ "jti": "f42150ef-2743-4ca0-ae06-a23b307edaca",}} > {{ "iss": "STS INT",}} > {{ "roles": [}} > {{ "READ",}} > {{ "UPDATE"}} > {{ ],}} > {{ "iat": 1649079679,}} > {{ "nbf": 1649079679,}} > {{ "exp": 1649086879,}} > {{ "aud": [}} > {{ "urn:mycompany:application:foo"}} > {{ ]}} > {{}}} > > I propose to improve this logic thus both roles in tokenized string as well > as a propery array list are properly parsed. > > Here a snippet of the debugger. The above example ends-up with two roles > "[READ" and " UPDATE]". > > !image-2022-04-05-14-08-09-726.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)