On a similar note, does anyone know why none of the CVE's were fixed in the Netty 3.x series? Netty is quite an established/mature library in the JVM ecosystem so it seems odd that they didn't do this.
On Wed, Aug 2, 2023 at 10:04 AM Matthew de Detrich < matthew.dedetr...@aiven.io> wrote: > > If you manage to move to Pekko and were still using classic remoting, > it's likely you are still on Akka 2.4 or 2.5. If you manage the update > to Pekko, going to Artery TCP is a small step. > > One of the reasons why I was saying this is that I was under the impression > that there are a non-trivial amount of users still on Akka 2.4 (not sure > why > this is the case but kerr was telling me this). > > > If people are interested in keeping it around and also opt in to > maintaining it (which in the first place means, making the tests for > it work *now*), than fine, but otherwise, being able to use it on > 1.0.x is already a big benefit. > > Since classic remoting is currently using Netty 3 which has CVE's > I don't think it's wise to encourage people that still happen to be > using classic remoting to stay on 1.0.x. If it wasn't for final > version of netty 3 having CVE's then I would have no qualms > for dropping it in the 1.1.x series (in fact if there was a > hypothetical netty 3 without CVE's we would have already > updated to it in the 1.0.x series and dropped classic remoting in > 1.1.x without a heartbeat). > > I would propose that if we do accept keeping classic remoting > and updating to Netty 4, we would mark the feature to be > dropped in 1.2.x and aside from that Netty 4 upgrade that > part of code would be untouched unless there are critical > bugs/regressions. > > On Tue, Aug 1, 2023 at 1:38 PM Johannes Rudolph < > johannes.rudo...@gmail.com> wrote: > >> We definitely should remove it for 1.1.x. There's no technical reason >> to keep it because the newer artery TCP transport just supersedes it. >> As discussed before, the problem with keeping old features around is >> "death by a thousand cuts". The classic remoting backend is the prime >> example of it because it is basically unmaintained for years and >> there's basically no expert knowledge available about how to maintain >> it or how to fix the existing bugs. Testing remoting backends has >> shown to be very complicated and often unreliable and being able to >> remove this particular component from the test matrix will be a huge >> improvement. >> >> On Mon, Jul 31, 2023 at 11:28 PM Matthew de Detrich >> <matthew.dedetr...@aiven.io.invalid> wrote: >> > I would prefer adding in netty 4 support for the classic transport >> > mechanism because it gives >> > people an upgrade path while allowing them to resolve the CVE issues. If >> > Pekko 1.1.x didn't >> > support the classic transport mechanism then it forces Pekko users to be >> > stuck on 1.0.x >> > with no easy upgrade path. >> >> We are not responsible for giving people an easy upgrade path when >> they were stuck on features like classic remoting which has basically >> been outdated for years. It is very important that, going forward, >> that we focus our attention on the most important features and make >> sure to not get stuck in maintaining old parts that we cannot (or >> don't want to) care for. >> >> If people are interested in keeping it around and also opt in to >> maintaining it (which in the first place means, making the tests for >> it work *now*), than fine, but otherwise, being able to use it on >> 1.0.x is already a big benefit. >> >> Apart from that the update path is pretty clear: >> * move to Pekko 1.0.x >> * move to Arterty TCP >> * move to Pekko 1.1.x >> >> If you manage to move to Pekko and were still using classic remoting, >> it's likely you are still on Akka 2.4 or 2.5. If you manage the update >> to Pekko, going to Artery TCP is a small step. >> >> Johannes >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> For additional commands, e-mail: dev-h...@pekko.apache.org >> >> > > -- > > 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
