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 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
