The netty maintenance asked akka team to migrate once back in 2012, but they never have a chance to do that, and the multi node testkit has been upgraded to Netty 4 ,only the classic transport is based on Netty 3.
In later version of Akka 2.8, they removed the classic transport too. I think we should better keep it before 2.x but maybe we can extract the netty4 transport to a dedicated jar is that's a concern. Shiping jars with CVEs is not good and Netty 4 have many improvements too. Flink community would you like pekko upgrade to Netty 4? If it is please vote and help the review, thanks. On 2023/09/12 08:29:04 Matthew de Detrich 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 Akka[1]. Ontop of this classical > remoting happens to be using netty3 which has known CVE's[2], 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 PR[3] 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 artery[4] > although the decision that Pekko ultimately makes may influence the > timeline (hence the reason for this thread). > > [1]: https://github.com/akka/akka/issues/31764 > [2]: https://mvnrepository.com/artifact/io.netty/netty/3.10.6.Final > [3]: https://github.com/apache/incubator-pekko/pull/643 > [4]: https://pekko.apache.org/docs/pekko/current/remoting-artery.html > > -- > > 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 >
