[PR] Bump cxf.aspectj.version from 1.9.21 to 1.9.21.1 [cxf]

2024-02-13 Thread via GitHub


dependabot[bot] opened a new pull request, #1688:
URL: https://github.com/apache/cxf/pull/1688

   Bumps `cxf.aspectj.version` from 1.9.21 to 1.9.21.1.
   Updates `org.aspectj:aspectjweaver` from 1.9.21 to 1.9.21.1
   
   Release notes
   Sourced from https://github.com/eclipse/org.aspectj/releases;>org.aspectj:aspectjweaver's
 releases.
   
   1.9.21.1
   Java 21 maintenance release.
   For load-time weaving (LTW) on JDK 16+, using --add-opens is 
no longer necessary!
   https://github.com/eclipse-aspectj/aspectj/blob/master/docs/release/README-1.9.21.adoc;>AspectJ
 1.9.21 release notes
   
   
   
   Commits
   
   See full diff in https://github.com/eclipse/org.aspectj/commits;>compare view
   
   
   
   
   Updates `org.aspectj:aspectjrt` from 1.9.21 to 1.9.21.1
   
   Release notes
   Sourced from https://github.com/eclipse/org.aspectj/releases;>org.aspectj:aspectjrt's 
releases.
   
   1.9.21.1
   Java 21 maintenance release.
   For load-time weaving (LTW) on JDK 16+, using --add-opens is 
no longer necessary!
   https://github.com/eclipse-aspectj/aspectj/blob/master/docs/release/README-1.9.21.adoc;>AspectJ
 1.9.21 release notes
   
   
   
   Commits
   
   See full diff in https://github.com/eclipse/org.aspectj/commits;>compare view
   
   
   
   
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot show  ignore conditions` will show all of 
the ignore conditions of the specified dependency
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[PR] Bump cxf.brave.version from 5.17.1 to 6.0.1 [cxf]

2024-02-13 Thread via GitHub


dependabot[bot] opened a new pull request, #1687:
URL: https://github.com/apache/cxf/pull/1687

   Bumps `cxf.brave.version` from 5.17.1 to 6.0.1.
   Updates `io.zipkin.brave:brave` from 5.17.1 to 6.0.1
   
   Release notes
   Sourced from https://github.com/openzipkin/brave/releases;>io.zipkin.brave:brave's 
releases.
   
   Brave 6.0.1 simplifies internals of the json encoder and kafka-streams 
instrumentation. It also fixes a bug where a TagThrowable 
passed to MutableSpanBytesEncoder.zipkinJsonV2 always used the key 
error even when set to something else. Finally https://github.com/reta;>@​reta fixed a flakey JMS 
integration test which was plaguing our CI builds!
   Full Changelog: https://github.com/openzipkin/brave/compare/6.0.0..6.0.1;>https://github.com/openzipkin/brave/compare/6.0.0..6.0.1
   Brave 6 removes all modules and functions deprecated in Brave 5.x. It no 
longer has any dependency on io.zipkin.zipkin2:zipkin. Special thanks to https://github.com/reta;>@​reta and https://github.com/anuraaga;>@​anuraaga for a lot of 
review support leading to this release!
   No more deprecated functions
   The final release of Brave 5 with deprecated functions was 5.18.1. 
Removing these functions was the only way to decouple Brave from zipkin's core 
library (io.zipkin.zipkin2:zipkin). However, this does not change Brave's floor 
Java 6 support. We still integration test this via the https://github.com/openzipkin/brave-example;>brave-example 
repository.
   Here's an example of a working Java 6 and Spring 2.5 application, which 
is 280KB smaller due to use of the lean combination of Brave 6 and Zipkin 
Reporter 3.x:
   # brave 5.18.1
   3860target/brave-example-webmvc25-1.0-SNAPSHOT.war
   # brave 6.0.0
   3580target/brave-example-webmvc25-1.0-SNAPSHOT.war
   
   No more io.zipkin.reporter2:zipkin-reporter or io.zipkin.zipkin2:zipkin 
dependencies
   https://central.sonatype.com/artifact/io.zipkin.brave/brave-bom;>io.zipkin.brave:brave-bom
 used to manage zipkin-reporter dependencies. Since Brave no longer has 
dependencies on zipkin, it no longer manages them.
   This impact is that users will need to manage their own versions for 
zipkin-reporter, likely via https://central.sonatype.com/artifact/io.zipkin.reporter2/zipkin-reporter-bom;>io.zipkin.reporter2:zipkin-reporter-bom
 described in the https://github.com/openzipkin/zipkin-reporter-java#library-releases;>zipkin-reporter
 README.
   To fully remove a zipkin core library dependency from your traced 
applications, use https://central.sonatype.com/artifact/io.zipkin.reporter2/zipkin-reporter-brave;>io.zipkin.reporter2:zipkin-reporter-brave
 https://github.com/openzipkin/zipkin-reporter-java/releases/tag/3.1.1;>3.x
 AsyncZipkinSpanHandler. This is described in the https://github.com/openzipkin/zipkin-reporter-java#library-releases;>zipkin-reporter
 README. You can expect currently maintained frameworks to do this on your 
behalf.
   Thanks for your patience with the major upgrade. Things like this allow 
easier maintenance and a longer life for Brave, particularly as zipkin-server 
moves ahead with later Java versions.
   Full Changelog: https://github.com/openzipkin/brave/compare/5.17.1..5.18.1;>https://github.com/openzipkin/brave/compare/5.17.1..5.18.1
   Brave 5.18 prepares for Brave 6 by deprecating instrumentation for 
libraries not released in 1.5-3.5 years including:
   
   context/rxjava2 - last released Feb 2021
   
   replaced by RxJava3, but unlikely this module will be ported as it 
wasn't used widely.
   
   
   instrumentation/dubbo-rpc - (alibaba) last released Dec 2021
   
   replaced by Apache Dubbo instrumentation/dubbo
   
   
   instrumentation/p6spy - last released July 2020
   
   project dormant
   
   
   instrumentation/sparkjava - last released July 2022
   
   project dormant
   
   
   
   A minor change is we changed the artifact we use to test MySQL 8 to 
com.mysql:mysql-connector-j  (instead of mysql:mysql-connector-java), to ensure 
we validate against current versions. Thanks https://github.com/m1ngyuan;>@​m1ngyuan for the help on 
this.
   Full Changelog: https://github.com/openzipkin/brave/compare/5.17.1..5.18.1;>https://github.com/openzipkin/brave/compare/5.17.1..5.18.1
   
   
   
   Commits
   
   https://github.com/openzipkin/brave/commit/03bbeca48ae1d578631a7aa9592c1be321263162;>03bbeca
 [maven-release-plugin] prepare release 6.0.1
   https://github.com/openzipkin/brave/commit/7158ba2cd74a3cd2a10717ccb2bd69b0940f3237;>7158ba2
 json: fixes incorrect handling of error tag (https://redirect.github.com/openzipkin/brave/issues/1415;>#1415)
   https://github.com/openzipkin/brave/commit/665e3e82043d33aecd09060c4c2df4d3dfbdcd31;>665e3e8
 removes IpLiteral dependency from ZipkinV2JsonWriter (https://redirect.github.com/openzipkin/brave/issues/1414;>#1414)
   https://github.com/openzipkin/brave/commit/710e7c33deb145c63583becafa259eb658f61c96;>710e7c3
 log4j12: uses version with CVEs only via invoker 

[PR] Bump cxf.netty.version from 4.1.106.Final to 4.1.107.Final [cxf]

2024-02-13 Thread via GitHub


dependabot[bot] opened a new pull request, #1686:
URL: https://github.com/apache/cxf/pull/1686

   Bumps `cxf.netty.version` from 4.1.106.Final to 4.1.107.Final.
   Updates `io.netty:netty-codec-http` from 4.1.106.Final to 4.1.107.Final
   
   Commits
   
   https://github.com/netty/netty/commit/1908d3a8b02b6ebd00b6c3c0f60cf31a8e31d2ca;>1908d3a
 [maven-release-plugin] prepare release netty-4.1.107.Final
   https://github.com/netty/netty/commit/8d7c11357cf567cc26fb6f22897b36f0c335f78f;>8d7c113
 Add ReferenceCountUtil.touch(...) calls before we store messages into… (https://redirect.github.com/netty/netty/issues/13838;>#13838)
   https://github.com/netty/netty/commit/f2542264c1589122365783d3abb92b4aa57700d8;>f254226
 Add reset API to IdleStateHandler (https://redirect.github.com/netty/netty/issues/13598;>#13598)
   https://github.com/netty/netty/commit/442165ecb8e03ac99bbccb31d78c599d68368f76;>442165e
 Save CRC32C Netty allocation to trigger ADLER32 and CRC32 reflective 
initiali...
   https://github.com/netty/netty/commit/b135e37e1bb311aba1cfe9bace8fbd6c14c81075;>b135e37
 Update Brotli4j to v1.16.0 (https://redirect.github.com/netty/netty/issues/13827;>#13827)
   https://github.com/netty/netty/commit/9f19909b7d5010e56ac8075e45e7b7c03ff08d96;>9f19909
 MathUtil.findNextPositivePowerOfTwo instead of JCTools' (https://redirect.github.com/netty/netty/issues/13833;>#13833)
   https://github.com/netty/netty/commit/59a8bd0708583982769b43f7b36bd8ef77f4c761;>59a8bd0
 Snappy: Use unsigned short to handle 2 ^ 16 input size instead of 2 ^ 15 (https://redirect.github.com/netty/netty/issues/13;>#13...
   https://github.com/netty/netty/commit/14e00f50d13d112a1a7a8eaa693c2363adeee629;>14e00f5
 Fix compile error
   https://github.com/netty/netty/commit/94d0cfb347780f1a1f9c7bf4ad4ecb477c5c1310;>94d0cfb
 Correctly override equals and hashCode for our OpenSslSession sub-types (https://redirect.github.com/netty/netty/issues/13829;>#13829)
   https://github.com/netty/netty/commit/f0e9b4041856231498df2fcd44cd96d6ddc57bb2;>f0e9b40
 Ensure key / values are shared between resumed sessions (https://redirect.github.com/netty/netty/issues/13819;>#13819)
   Additional commits viewable in https://github.com/netty/netty/compare/netty-4.1.106.Final...netty-4.1.107.Final;>compare
 view
   
   
   
   
   Updates `io.netty:netty-codec-http2` from 4.1.106.Final to 4.1.107.Final
   
   Commits
   
   https://github.com/netty/netty/commit/1908d3a8b02b6ebd00b6c3c0f60cf31a8e31d2ca;>1908d3a
 [maven-release-plugin] prepare release netty-4.1.107.Final
   https://github.com/netty/netty/commit/8d7c11357cf567cc26fb6f22897b36f0c335f78f;>8d7c113
 Add ReferenceCountUtil.touch(...) calls before we store messages into… (https://redirect.github.com/netty/netty/issues/13838;>#13838)
   https://github.com/netty/netty/commit/f2542264c1589122365783d3abb92b4aa57700d8;>f254226
 Add reset API to IdleStateHandler (https://redirect.github.com/netty/netty/issues/13598;>#13598)
   https://github.com/netty/netty/commit/442165ecb8e03ac99bbccb31d78c599d68368f76;>442165e
 Save CRC32C Netty allocation to trigger ADLER32 and CRC32 reflective 
initiali...
   https://github.com/netty/netty/commit/b135e37e1bb311aba1cfe9bace8fbd6c14c81075;>b135e37
 Update Brotli4j to v1.16.0 (https://redirect.github.com/netty/netty/issues/13827;>#13827)
   https://github.com/netty/netty/commit/9f19909b7d5010e56ac8075e45e7b7c03ff08d96;>9f19909
 MathUtil.findNextPositivePowerOfTwo instead of JCTools' (https://redirect.github.com/netty/netty/issues/13833;>#13833)
   https://github.com/netty/netty/commit/59a8bd0708583982769b43f7b36bd8ef77f4c761;>59a8bd0
 Snappy: Use unsigned short to handle 2 ^ 16 input size instead of 2 ^ 15 (https://redirect.github.com/netty/netty/issues/13;>#13...
   https://github.com/netty/netty/commit/14e00f50d13d112a1a7a8eaa693c2363adeee629;>14e00f5
 Fix compile error
   https://github.com/netty/netty/commit/94d0cfb347780f1a1f9c7bf4ad4ecb477c5c1310;>94d0cfb
 Correctly override equals and hashCode for our OpenSslSession sub-types (https://redirect.github.com/netty/netty/issues/13829;>#13829)
   https://github.com/netty/netty/commit/f0e9b4041856231498df2fcd44cd96d6ddc57bb2;>f0e9b40
 Ensure key / values are shared between resumed sessions (https://redirect.github.com/netty/netty/issues/13819;>#13819)
   Additional commits viewable in https://github.com/netty/netty/compare/netty-4.1.106.Final...netty-4.1.107.Final;>compare
 view
   
   
   
   
   Updates `io.netty:netty-codec-socks` from 4.1.106.Final to 4.1.107.Final
   
   Commits
   
   https://github.com/netty/netty/commit/1908d3a8b02b6ebd00b6c3c0f60cf31a8e31d2ca;>1908d3a
 [maven-release-plugin] prepare release netty-4.1.107.Final
   https://github.com/netty/netty/commit/8d7c11357cf567cc26fb6f22897b36f0c335f78f;>8d7c113
 Add ReferenceCountUtil.touch(...) calls before we store messages into… (https://redirect.github.com/netty/netty/issues/13838;>#13838)
   

Re: Plans for release 4.0.4?

2024-02-13 Thread Andriy Redko
Hi Colm,

I think it would be good to have a release soon-ish, but by and large, I don't 
think
we have hard deadline for it, please feel free to proceed as per your 
judgement. 
Thank you.
 
Best Regards,
    Andriy Redko 

> Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
> have time to do this and WSS4J before the next CXF release?

> Colm.

> On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang  wrote:
>> Thanks Colm!
>> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh  
>> wrote:
>>> Yes, I'll call a vote today on WSS4J 3.0.3.
>>> Colm.
>>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang  wrote:
 +1 to release Apache CXF 4.0.4
 @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon?
 Thanks!
 Freeman
 On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek  wrote:
> Hi,
> just for your information, the PR 
> (https://github.com/apache/cxf/pull/1660)
> requires version of wss4f to be 3.0.3 (to contain
> https://issues.apache.org/jira/browse/WSS-709)
> Best regards,
> Jiri
> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga  wrote:
>> Thanks, great to hear that, Andriy.

>> It would be great if we could get
>> https://github.com/apache/cxf/pull/1660 merged in some form before the
>> release.
>> The main motivation is to be able to run CXF on FIPS-enabled systems. If
>> the customized algo suite, that the PR proposes, is questionable, I'd be
>> also fine with introducing a couple of new suites with fixed
>> non-standard names, like already done in the past for fixing CVEs. It
>> would be nice to hear other community members' thoughts.
>> Thanks again,
>> -- Peter
>> On 13/02/2024 02:35, Andriy Redko wrote:
>>> Hi Peter,
>>> Thanks a lot for reminding, I belive we are long overdue on that, @Dan,
>> @Colm
>>> may need your help please preparing the next release train (or any
>> objection folks)?
>>> Thank you!
>>> Best Regards,
>>>      Andriy Redko
 Hi,
 we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
>> going to be a LTS (Long Term Support) release.
 I wonder whether we could count on getting CXF 4.0.4 by February 21st
>> to be able to use it in that release?
 Thanks,
 -- Peter
> --
> Jiri Ondrusek 
> Senior Software Engineer
> Red Hat Fuse



Re: Plans for release 4.0.4?

2024-02-13 Thread Andrey Redko
Thanks Colm!

Best Regards,
Andriy Redko

On Tue, Feb 13, 2024, 10:18 AM Colm O hEigeartaigh 
wrote:

> Yes, I'll call a vote today on WSS4J 3.0.3.
>
> Colm.
>
> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> >
> > +1 to release Apache CXF 4.0.4
> >
> > @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon?
> >
> > Thanks!
> > Freeman
> >
> > On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> >>
> >> Hi,
> >>
> >> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> >> requires version of wss4f to be 3.0.3 (to contain
> >> https://issues.apache.org/jira/browse/WSS-709)
> >>
> >> Best regards,
> >> Jiri
> >>
> >> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> >>
> >> > Thanks, great to hear that, Andriy.
> >> >
> >> > It would be great if we could get
> >> > https://github.com/apache/cxf/pull/1660 merged in some form before
> the
> >> > release.
> >> > The main motivation is to be able to run CXF on FIPS-enabled systems.
> If
> >> > the customized algo suite, that the PR proposes, is questionable, I'd
> be
> >> > also fine with introducing a couple of new suites with fixed
> >> > non-standard names, like already done in the past for fixing CVEs. It
> >> > would be nice to hear other community members' thoughts.
> >> >
> >> > Thanks again,
> >> >
> >> > -- Peter
> >> >
> >> > On 13/02/2024 02:35, Andriy Redko wrote:
> >> > > Hi Peter,
> >> > >
> >> > > Thanks a lot for reminding, I belive we are long overdue on that,
> @Dan,
> >> > @Colm
> >> > > may need your help please preparing the next release train (or any
> >> > objection folks)?
> >> > > Thank you!
> >> > >
> >> > > Best Regards,
> >> > >  Andriy Redko
> >> > >
> >> > >> Hi,
> >> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
> >> > going to be a LTS (Long Term Support) release.
> >> > >> I wonder whether we could count on getting CXF 4.0.4 by February
> 21st
> >> > to be able to use it in that release?
> >> > >> Thanks,
> >> > >> -- Peter
> >> > >
> >> >
> >> >
> >>
> >> --
> >> Jiri Ondrusek 
> >> Senior Software Engineer
> >> Red Hat Fuse
>


Re: Plans for release 4.0.4?

2024-02-13 Thread Freeman Fang
Thanks for the update Colm!

Please go ahead to release Santuario then WSS4J, and I believe the next CXF
release needs those changes anyway.

Best Regards
Freeman

On Tue, Feb 13, 2024 at 10:51 AM Colm O hEigeartaigh 
wrote:

> Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
> have time to do this and WSS4J before the next CXF release?
>
> Colm.
>
> On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang 
> wrote:
> >
> > Thanks Colm!
> >
> > On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh <
> cohei...@apache.org> wrote:
> >>
> >> Yes, I'll call a vote today on WSS4J 3.0.3.
> >>
> >> Colm.
> >>
> >> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> >> >
> >> > +1 to release Apache CXF 4.0.4
> >> >
> >> > @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release
> soon?
> >> >
> >> > Thanks!
> >> > Freeman
> >> >
> >> > On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> >> >> requires version of wss4f to be 3.0.3 (to contain
> >> >> https://issues.apache.org/jira/browse/WSS-709)
> >> >>
> >> >> Best regards,
> >> >> Jiri
> >> >>
> >> >> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> >> >>
> >> >> > Thanks, great to hear that, Andriy.
> >> >> >
> >> >> > It would be great if we could get
> >> >> > https://github.com/apache/cxf/pull/1660 merged in some form
> before the
> >> >> > release.
> >> >> > The main motivation is to be able to run CXF on FIPS-enabled
> systems. If
> >> >> > the customized algo suite, that the PR proposes, is questionable,
> I'd be
> >> >> > also fine with introducing a couple of new suites with fixed
> >> >> > non-standard names, like already done in the past for fixing CVEs.
> It
> >> >> > would be nice to hear other community members' thoughts.
> >> >> >
> >> >> > Thanks again,
> >> >> >
> >> >> > -- Peter
> >> >> >
> >> >> > On 13/02/2024 02:35, Andriy Redko wrote:
> >> >> > > Hi Peter,
> >> >> > >
> >> >> > > Thanks a lot for reminding, I belive we are long overdue on
> that, @Dan,
> >> >> > @Colm
> >> >> > > may need your help please preparing the next release train (or
> any
> >> >> > objection folks)?
> >> >> > > Thank you!
> >> >> > >
> >> >> > > Best Regards,
> >> >> > >  Andriy Redko
> >> >> > >
> >> >> > >> Hi,
> >> >> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8
> which is
> >> >> > going to be a LTS (Long Term Support) release.
> >> >> > >> I wonder whether we could count on getting CXF 4.0.4 by
> February 21st
> >> >> > to be able to use it in that release?
> >> >> > >> Thanks,
> >> >> > >> -- Peter
> >> >> > >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> Jiri Ondrusek 
> >> >> Senior Software Engineer
> >> >> Red Hat Fuse
>


Re: Plans for release 4.0.4?

2024-02-13 Thread Colm O hEigeartaigh
Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
have time to do this and WSS4J before the next CXF release?

Colm.

On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang  wrote:
>
> Thanks Colm!
>
> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh  
> wrote:
>>
>> Yes, I'll call a vote today on WSS4J 3.0.3.
>>
>> Colm.
>>
>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang  wrote:
>> >
>> > +1 to release Apache CXF 4.0.4
>> >
>> > @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon?
>> >
>> > Thanks!
>> > Freeman
>> >
>> > On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek  wrote:
>> >>
>> >> Hi,
>> >>
>> >> just for your information, the PR 
>> >> (https://github.com/apache/cxf/pull/1660)
>> >> requires version of wss4f to be 3.0.3 (to contain
>> >> https://issues.apache.org/jira/browse/WSS-709)
>> >>
>> >> Best regards,
>> >> Jiri
>> >>
>> >> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga  wrote:
>> >>
>> >> > Thanks, great to hear that, Andriy.
>> >> >
>> >> > It would be great if we could get
>> >> > https://github.com/apache/cxf/pull/1660 merged in some form before the
>> >> > release.
>> >> > The main motivation is to be able to run CXF on FIPS-enabled systems. If
>> >> > the customized algo suite, that the PR proposes, is questionable, I'd be
>> >> > also fine with introducing a couple of new suites with fixed
>> >> > non-standard names, like already done in the past for fixing CVEs. It
>> >> > would be nice to hear other community members' thoughts.
>> >> >
>> >> > Thanks again,
>> >> >
>> >> > -- Peter
>> >> >
>> >> > On 13/02/2024 02:35, Andriy Redko wrote:
>> >> > > Hi Peter,
>> >> > >
>> >> > > Thanks a lot for reminding, I belive we are long overdue on that, 
>> >> > > @Dan,
>> >> > @Colm
>> >> > > may need your help please preparing the next release train (or any
>> >> > objection folks)?
>> >> > > Thank you!
>> >> > >
>> >> > > Best Regards,
>> >> > >  Andriy Redko
>> >> > >
>> >> > >> Hi,
>> >> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
>> >> > going to be a LTS (Long Term Support) release.
>> >> > >> I wonder whether we could count on getting CXF 4.0.4 by February 21st
>> >> > to be able to use it in that release?
>> >> > >> Thanks,
>> >> > >> -- Peter
>> >> > >
>> >> >
>> >> >
>> >>
>> >> --
>> >> Jiri Ondrusek 
>> >> Senior Software Engineer
>> >> Red Hat Fuse


Re: Plans for release 4.0.4?

2024-02-13 Thread Freeman Fang
Thanks Colm!

On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh 
wrote:

> Yes, I'll call a vote today on WSS4J 3.0.3.
>
> Colm.
>
> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> >
> > +1 to release Apache CXF 4.0.4
> >
> > @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon?
> >
> > Thanks!
> > Freeman
> >
> > On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> >>
> >> Hi,
> >>
> >> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> >> requires version of wss4f to be 3.0.3 (to contain
> >> https://issues.apache.org/jira/browse/WSS-709)
> >>
> >> Best regards,
> >> Jiri
> >>
> >> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> >>
> >> > Thanks, great to hear that, Andriy.
> >> >
> >> > It would be great if we could get
> >> > https://github.com/apache/cxf/pull/1660 merged in some form before
> the
> >> > release.
> >> > The main motivation is to be able to run CXF on FIPS-enabled systems.
> If
> >> > the customized algo suite, that the PR proposes, is questionable, I'd
> be
> >> > also fine with introducing a couple of new suites with fixed
> >> > non-standard names, like already done in the past for fixing CVEs. It
> >> > would be nice to hear other community members' thoughts.
> >> >
> >> > Thanks again,
> >> >
> >> > -- Peter
> >> >
> >> > On 13/02/2024 02:35, Andriy Redko wrote:
> >> > > Hi Peter,
> >> > >
> >> > > Thanks a lot for reminding, I belive we are long overdue on that,
> @Dan,
> >> > @Colm
> >> > > may need your help please preparing the next release train (or any
> >> > objection folks)?
> >> > > Thank you!
> >> > >
> >> > > Best Regards,
> >> > >  Andriy Redko
> >> > >
> >> > >> Hi,
> >> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
> >> > going to be a LTS (Long Term Support) release.
> >> > >> I wonder whether we could count on getting CXF 4.0.4 by February
> 21st
> >> > to be able to use it in that release?
> >> > >> Thanks,
> >> > >> -- Peter
> >> > >
> >> >
> >> >
> >>
> >> --
> >> Jiri Ondrusek 
> >> Senior Software Engineer
> >> Red Hat Fuse
>


Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1488072808


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -140,9 +164,116 @@ protected void parseCustomAssertion(Assertion assertion) {
 } else if ("Basic256GCM".equals(assertionName)) {
 
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("Basic256GCM"));
 getAlgorithmSuiteType().setNamespace(assertionNamespace);
+} else if ("CustomizedAlgorithmSuite".equals(assertionName)) {
+
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("CustomizedAlgorithmSuite"));
+getAlgorithmSuiteType().setNamespace(assertionNamespace);
 }
 }
 }
 
 
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Message message) 
{
+
+Map values = message.getContextualPropertyKeys()
+.stream()
+.filter(k -> 
k.startsWith(SecurityConstants.CUSTOM_ALG_SUITE_PREFIX))
+.collect(Collectors.toMap(Function.identity(), k -> 
message.getContextualProperty(k)));
+
+return customize(suiteType, values);
+
+}
+
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Map values) {
+
+//customization happens only for CustomizedAlgorithmSuite
+if (suiteType != null && 
!"CustomizedAlgorithmSuite".equals(suiteType.getName())) {
+return suiteType;
+}
+
+
+AlgorithmSuite.AlgorithmSuiteType retVal = suiteType != null ? 
suiteType
+: new AlgorithmSuite.AlgorithmSuiteType(null, null, null, null,
+null, null, null,

Review Comment:
   fixed



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


ffang commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1941778643

   > @ffang I removed the null AlgorithmSuiteType from the suite loader.
   
   Thanks @JiriOndrusek !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


ffang commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1480553067


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -140,9 +164,116 @@ protected void parseCustomAssertion(Assertion assertion) {
 } else if ("Basic256GCM".equals(assertionName)) {
 
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("Basic256GCM"));
 getAlgorithmSuiteType().setNamespace(assertionNamespace);
+} else if ("CustomizedAlgorithmSuite".equals(assertionName)) {
+
setAlgorithmSuiteType(ALGORITHM_SUITE_TYPES.get("CustomizedAlgorithmSuite"));
+getAlgorithmSuiteType().setNamespace(assertionNamespace);
 }
 }
 }
 
 
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Message message) 
{
+
+Map values = message.getContextualPropertyKeys()
+.stream()
+.filter(k -> 
k.startsWith(SecurityConstants.CUSTOM_ALG_SUITE_PREFIX))
+.collect(Collectors.toMap(Function.identity(), k -> 
message.getContextualProperty(k)));
+
+return customize(suiteType, values);
+
+}
+
+public static AlgorithmSuite.AlgorithmSuiteType 
customize(AlgorithmSuite.AlgorithmSuiteType suiteType,
+  Map values) {
+
+//customization happens only for CustomizedAlgorithmSuite
+if (suiteType != null && 
!"CustomizedAlgorithmSuite".equals(suiteType.getName())) {
+return suiteType;
+}
+
+
+AlgorithmSuite.AlgorithmSuiteType retVal = suiteType != null ? 
suiteType
+: new AlgorithmSuite.AlgorithmSuiteType(null, null, null, null,
+null, null, null,

Review Comment:
   Hi @JiriOndrusek ,
   
   I believe here the AlgorithmSuiteType name shouldn't be null anyway.
   Actually I think if the original suiteType is null, we shouldn't create a 
new one and customize it, we should just skip the customization.
   
   Freeman
   



##
systests/ws-security/src/test/resources/wsdl_systest_wssec/wssec10/WsSecurity10_policy_customizedAlgorithmSuite.wsdl:
##
@@ -0,0 +1,178 @@
+
+
+http://schemas.xmlsoap.org/wsdl/; 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/; 
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata; 
xmlns:tns="http://apache.cxf.org/; 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing; 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy; 
xmlns:wssec10test="http://WSSec/wssec10; 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl; 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/; 
xmlns:wsa10="http://www.w3.org/2005/08/addressing; 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex; 
targetNamespace="http://apache.cxf.org/;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient;>
+
+
+
+
+
+
+
+
+http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never;>
+
+
+
+
+
+
+
+
+

Review Comment:
   Hi @JiriOndrusek ,
   
   Though I believe technically it's doable,  like in the 
org.apache.cxf.ws.security.policy.custom.AlgorithmSuiteBuilder constructor you 
can get nestedPolicyElement which is a DOM element
   ```
   final Element nestedPolicyElement = 
SPUtils.getFirstPolicyChildElement(element);
   ```
   So you can get all child element from this point actually.
   
   However, I'm hesitant to do it because this behaviour isn't aligned with 
current properties implementations used in WSS4J and CXF. You can find more 
discussion in 
   https://issues.apache.org/jira/browse/CXF-8971
   
   Best Regards
   Freeman



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on 

Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1941774951

   @ffang I removed the null AlgorithmSuiteType from the suite loader.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on code in PR #1660:
URL: https://github.com/apache/cxf/pull/1660#discussion_r1488064493


##
rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/custom/DefaultAlgorithmSuiteLoader.java:
##
@@ -53,6 +59,8 @@ public AlgorithmSuite getAlgorithmSuite(Bus bus, 
SPConstants.SPVersion version,
 assertions.put(qName, new PrimitiveAssertion(qName));
 qName = new QName(ns, "Basic256GCM");
 assertions.put(qName, new PrimitiveAssertion(qName));
+qName = new QName(ns, "CustomizedAlgorithmSuite");

Review Comment:
   renamed



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: Plans for release 4.0.4?

2024-02-13 Thread Colm O hEigeartaigh
Yes, I'll call a vote today on WSS4J 3.0.3.

Colm.

On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang  wrote:
>
> +1 to release Apache CXF 4.0.4
>
> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon?
>
> Thanks!
> Freeman
>
> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek  wrote:
>>
>> Hi,
>>
>> just for your information, the PR (https://github.com/apache/cxf/pull/1660)
>> requires version of wss4f to be 3.0.3 (to contain
>> https://issues.apache.org/jira/browse/WSS-709)
>>
>> Best regards,
>> Jiri
>>
>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga  wrote:
>>
>> > Thanks, great to hear that, Andriy.
>> >
>> > It would be great if we could get
>> > https://github.com/apache/cxf/pull/1660 merged in some form before the
>> > release.
>> > The main motivation is to be able to run CXF on FIPS-enabled systems. If
>> > the customized algo suite, that the PR proposes, is questionable, I'd be
>> > also fine with introducing a couple of new suites with fixed
>> > non-standard names, like already done in the past for fixing CVEs. It
>> > would be nice to hear other community members' thoughts.
>> >
>> > Thanks again,
>> >
>> > -- Peter
>> >
>> > On 13/02/2024 02:35, Andriy Redko wrote:
>> > > Hi Peter,
>> > >
>> > > Thanks a lot for reminding, I belive we are long overdue on that, @Dan,
>> > @Colm
>> > > may need your help please preparing the next release train (or any
>> > objection folks)?
>> > > Thank you!
>> > >
>> > > Best Regards,
>> > >  Andriy Redko
>> > >
>> > >> Hi,
>> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
>> > going to be a LTS (Long Term Support) release.
>> > >> I wonder whether we could count on getting CXF 4.0.4 by February 21st
>> > to be able to use it in that release?
>> > >> Thanks,
>> > >> -- Peter
>> > >
>> >
>> >
>>
>> --
>> Jiri Ondrusek 
>> Senior Software Engineer
>> Red Hat Fuse


Re: Plans for release 4.0.4?

2024-02-13 Thread Freeman Fang
+1 to release Apache CXF 4.0.4

@Colm O hEigeartaigh  Any chance we could have a WSS4J
3.0.3 release soon?

Thanks!
Freeman

On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek  wrote:

> Hi,
>
> just for your information, the PR (https://github.com/apache/cxf/pull/1660
> )
> requires version of wss4f to be 3.0.3 (to contain
> https://issues.apache.org/jira/browse/WSS-709)
>
> Best regards,
> Jiri
>
> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga  wrote:
>
> > Thanks, great to hear that, Andriy.
> >
> > It would be great if we could get
> > https://github.com/apache/cxf/pull/1660 merged in some form before the
> > release.
> > The main motivation is to be able to run CXF on FIPS-enabled systems. If
> > the customized algo suite, that the PR proposes, is questionable, I'd be
> > also fine with introducing a couple of new suites with fixed
> > non-standard names, like already done in the past for fixing CVEs. It
> > would be nice to hear other community members' thoughts.
> >
> > Thanks again,
> >
> > -- Peter
> >
> > On 13/02/2024 02:35, Andriy Redko wrote:
> > > Hi Peter,
> > >
> > > Thanks a lot for reminding, I belive we are long overdue on that, @Dan,
> > @Colm
> > > may need your help please preparing the next release train (or any
> > objection folks)?
> > > Thank you!
> > >
> > > Best Regards,
> > >  Andriy Redko
> > >
> > >> Hi,
> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
> > going to be a LTS (Long Term Support) release.
> > >> I wonder whether we could count on getting CXF 4.0.4 by February 21st
> > to be able to use it in that release?
> > >> Thanks,
> > >> -- Peter
> > >
> >
> >
>
> --
> Jiri Ondrusek 
> Senior Software Engineer
> Red Hat Fuse
>


[PR] CXF-8977: add support for MTOM Serialization Policy Assertion 1.1 [cxf]

2024-02-13 Thread via GitHub


daspilker opened a new pull request, #1685:
URL: https://github.com/apache/cxf/pull/1685

   (no comment)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: Plans for release 4.0.4?

2024-02-13 Thread Jiri Ondrusek
Hi,

just for your information, the PR (https://github.com/apache/cxf/pull/1660)
requires version of wss4f to be 3.0.3 (to contain
https://issues.apache.org/jira/browse/WSS-709)

Best regards,
Jiri

On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga  wrote:

> Thanks, great to hear that, Andriy.
>
> It would be great if we could get
> https://github.com/apache/cxf/pull/1660 merged in some form before the
> release.
> The main motivation is to be able to run CXF on FIPS-enabled systems. If
> the customized algo suite, that the PR proposes, is questionable, I'd be
> also fine with introducing a couple of new suites with fixed
> non-standard names, like already done in the past for fixing CVEs. It
> would be nice to hear other community members' thoughts.
>
> Thanks again,
>
> -- Peter
>
> On 13/02/2024 02:35, Andriy Redko wrote:
> > Hi Peter,
> >
> > Thanks a lot for reminding, I belive we are long overdue on that, @Dan,
> @Colm
> > may need your help please preparing the next release train (or any
> objection folks)?
> > Thank you!
> >
> > Best Regards,
> >  Andriy Redko
> >
> >> Hi,
> >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
> going to be a LTS (Long Term Support) release.
> >> I wonder whether we could count on getting CXF 4.0.4 by February 21st
> to be able to use it in that release?
> >> Thanks,
> >> -- Peter
> >
>
>

-- 
Jiri Ondrusek 
Senior Software Engineer
Red Hat Fuse


Re: [PR] Introduction of CustomerizedAlgorithmSuite (CXF-8971) [cxf]

2024-02-13 Thread via GitHub


JiriOndrusek commented on PR #1660:
URL: https://github.com/apache/cxf/pull/1660#issuecomment-1941354036

   PR requires update of **wss4j** to **3.0.3** before merging


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: Plans for release 4.0.4?

2024-02-13 Thread Peter Palaga

Thanks, great to hear that, Andriy.

It would be great if we could get 
https://github.com/apache/cxf/pull/1660 merged in some form before the 
release.
The main motivation is to be able to run CXF on FIPS-enabled systems. If 
the customized algo suite, that the PR proposes, is questionable, I'd be 
also fine with introducing a couple of new suites with fixed 
non-standard names, like already done in the past for fixing CVEs. It 
would be nice to hear other community members' thoughts.


Thanks again,

-- Peter

On 13/02/2024 02:35, Andriy Redko wrote:

Hi Peter,

Thanks a lot for reminding, I belive we are long overdue on that, @Dan, @Colm
may need your help please preparing the next release train (or any objection 
folks)?
Thank you!
  
Best Regards,

     Andriy Redko


Hi,
we are preparing Quarkus CXF to release it for Quarkus 3.8 which is going to be 
a LTS (Long Term Support) release.
I wonder whether we could count on getting CXF 4.0.4 by February 21st to be 
able to use it in that release?
Thanks,
-- Peter