All the relatived changes have been merged,Which is mainly for CVEs, and there are some changes relative to performance too.
Currently pekko only releases snapshot version, if you decide to contains it in 1.19， will need pekko1.1.0 to release before right? On 2023/09/20 14:29:45 Ferenc Csaky wrote: > That is a fair point. It not fixes a bug per se, but it would mitigate > security vulnerabilities (Netty 3.x CVEs), so my thought was it might qualify > it for addressing in a patch release. > > IMO handling security vulnerabilities is a gray area, if it only requires to > bump some deps that are only used internally, it can be considered as a patch > compatible change. > > I am not sure at this point what changes would be required to use the updated > Pekko version, so it is possible that we can only introduce it in 1.19, just > wanted to clarify my thought process. > > > ------- Original Message ------- > On Wednesday, September 20th, 2023 at 14:26, Martijn Visser > <martijnvis...@apache.org> wrote: > > > > > > > > Just chipping in that I don't think we should add Pekko changes in a > > patch release, because I think the Pekko related changes don't fix a > > bug. > > > > On Tue, Sep 19, 2023 at 9:06 PM Ferenc Csaky ferenc.cs...@pm.me.invalid > > wrote: > > > > > I think that is totally fine, because any Pekko related changes can only > > > be added to the first patch release of 1.18 at this point, as there is an > > > RC0 [1] already so the release process will be initiated soon. > > > > > > I am glad the mentioned PR got merged, did not have the chance to review. > > > > > > [1] https://lists.apache.org/thread/5x28rp3zct4p603hm4zdwx6kfr101w38 > > > > > > ------- Original Message ------- > > > On Monday, September 18th, 2023 at 14:20, Matthew de Detrich > > > matthew.dedetr...@aiven.io.INVALID wrote: > > > > > > > I think that the end of September is too soon for a Pekko 1.1.x, there > > > > are > > > > still more things > > > > that we would like to merge before making a release. > > > > > > > > Good news is that the PR to migrate to netty4 for classic remoting has > > > > been > > > > merged > > > > (see https://github.com/apache/incubator-pekko/pull/643). Improvements > > > > are > > > > also > > > > still be done, so the next minor version release of Pekko (1.1.0) will > > > > contain these > > > > changes. > > > > > > > > On Wed, Sep 13, 2023 at 11:22 AM Ferenc Csaky ferenc.cs...@pm.me.invalid > > > > > > > > wrote: > > > > > > > > > The target release date for 1.18 is the end of Sept [1], but I'm not > > > > > sure > > > > > everything will come together by then. Maybe it will pushed by a > > > > > couple > > > > > days. > > > > > > > > > > I'm happy to help out, even making the Flink related changes when > > > > > we're at > > > > > that point. > > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/FLINK/1.18+Release > > > > > > > > > > ------- Original Message ------- > > > > > On Tuesday, September 12th, 2023 at 17:43, He Pin he...@apache.org > > > > > wrote: > > > > > > > > > > > Hi Ferenc: > > > > > > What's the ETA of the Flink 1.18? I think we should beable to > > > > > > collaborate on this，and at work we are using Flink too. > > > > > > > > > > > > On 2023/09/12 15:16:11 Ferenc Csaky wrote: > > > > > > > > > > > > > Hi Matthew, > > > > > > > > > > > > > > Thanks for bringing this up! Cca half a year ago I started to > > > > > > > work on > > > > > > > an Akka Artery migration, there is a draft PR for that 1. It > > > > > > > might be an > > > > > > > option to revive that work and point it against Pekko instead. > > > > > > > Although I > > > > > > > would highlight FLINK-29281 2 which will replace the whole RPC > > > > > > > implementation in Flink to a gRPC-based one when it is done. > > > > > > > > > > > > > > I am not sure about the progess on the gRPC work, it looks > > > > > > > hanging for > > > > > > > a while now, so I think if there is a chance to replace Netty3 > > > > > > > with Netty4 > > > > > > > in Pekko in the short term it would benefit Flink and then we can > > > > > > > decide if > > > > > > > it would worth to upgrade to Artery, or how fast the gRPC > > > > > > > solution can be > > > > > > > done and then it will not be necessary. > > > > > > > > > > > > > > All in all, in the short term I think Flink would benefit to have > > > > > > > that > > > > > > > mentioned PR 3 merged, then the updated Pekko version could be > > > > > > > included in > > > > > > > the first 1.18 patch probably to mitigate those pesky Netty3 CVEs > > > > > > > that are > > > > > > > carried for a while ASAP. > > > > > > > > > > > > > > Cheers, > > > > > > > Ferenc > > > > > > > > > > > > > > 1 https://github.com/apache/flink/pull/22271 > > > > > > > 2 https://issues.apache.org/jira/browse/FLINK-29281 > > > > > > > 3 https://github.com/apache/incubator-pekko/pull/643 > > > > > > > > > > > > > > ------- Original Message ------- > > > > > > > On Tuesday, September 12th, 2023 at 10:29, Matthew de Detrich > > > > > > > matthew.dedetr...@aiven.io.INVALID wrote: > > > > > > > > > > > > > > > It's come to my attention that Flink is using Pekko's classical > > > > > > > > remoting, > > > > > > > > if this is the case then I would recommend making a response at > > > > > > > > https://lists.apache.org/thread/19h2wrs2om91g5vhnftv583fo0ddfshm > > > > > > > > . > > > > > > > > > > > > > > > > Quick summary of what is being discussed is what to do with > > > > > > > > Pekko's > > > > > > > > classical remoting. Classic remoting is considered deprecated > > > > > > > > since > > > > > > > > 2019, > > > > > > > > an artifact that we inherited from Akka1. Ontop of this > > > > > > > > classical > > > > > > > > remoting happens to be using netty3 which has known CVE's2, > > > > > > > > these > > > > > > > > CVE's > > > > > > > > were never fixed in the netty3 series. > > > > > > > > > > > > > > > > The question is what should be done given this, i.e. some > > > > > > > > people in > > > > > > > > the > > > > > > > > Pekko community are wanting to drop classical remoting as > > > > > > > > quickly as > > > > > > > > possible (i.e. even sooner then what semver allows but this is > > > > > > > > being > > > > > > > > discussed) and others are wanting to leave it as it is (even > > > > > > > > with the > > > > > > > > CVE's) since we don't want to incentivize and/or create > > > > > > > > impression > > > > > > > > that we > > > > > > > > are officially supporting it. There is also a currently open PR3 > > > > > > > > which > > > > > > > > upgrades Pekko's classical remoting's from netty3 to netty4 > > > > > > > > with the > > > > > > > > primary motivator being removing said CVE's. > > > > > > > > > > > > > > > > My personal position on the matter is that Pekko shouldn't drop > > > > > > > > classical > > > > > > > > remoting until 2.0.x (to satisfy semver) while also updating > > > > > > > > Pekko's > > > > > > > > classical remoting netty dependency to netty4 so that we are not > > > > > > > > shipping > > > > > > > > Pekko with known CVE's (if this gets approved such a change > > > > > > > > would > > > > > > > > likely > > > > > > > > land in Pekko 1.1.0). As is customary, such a decision should be > > > > > > > > agreed > > > > > > > > upon broadly in the Pekko community. > > > > > > > > > > > > > > > > Note that regardless of this change, it's recommended that a > > > > > > > > plan > > > > > > > > should be > > > > > > > > made at some point by Flink to move from classical remoting to > > > > > > > > artery4 > > > > > > > > although the decision that Pekko ultimately makes may influence > > > > > > > > the > > > > > > > > timeline (hence the reason for this thread). > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > > > Aiven Deutschland GmbH > > > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > > > m: +491603708037 > > > > > > > > > > > > > > > > w: aiven.io e: matthew.dedetr...@aiven.io > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > Aiven Deutschland GmbH > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > m: +491603708037 > > > > > > > > w: aiven.io e: matthew.dedetr...@aiven.io >
