#i2p-dev (irc2p) | 2.7.0-4

justmessin hey does anyone know whos responsible for maintaining i2p docker images on geti2p ?

eyedeekay justmessin it's me, next tag will fix the issue, until then build from source, i.e.

eyedeekay docker built -t geti2p/i2p .

obscuratus Why do we have both Apache Tomcat and Eclipse Jetty? Aren't these doing the same thing?

obscuratus Also, both of these packages are out-of-date. With Jetty being way out-of-date. And I think Jetty is pretty important in I2P.

obscuratus github.com/eclipse/jetty.project/issues/7958

eyedeekay Re: tomcat vs jetty, IIRC it has something to do with plugins but I do not remember specifically what it was. I will need to know soon because it affects i2p.i2p-bote so I'll let you know when I find out.

eyedeekay Re: jetty out-of-date, there was a rationale offered to me many years ago for sticking with a stable jetty version due to our use of jetty, but what I'm seeing here may defy that rationale so I'm not sure

eyedeekay It looks to me that the version which we need to be on is the 9.4.x series, which is in fact what we depend on in Debian

eyedeekay 9.4.x being stable and EOCS but not EOL

obscuratus So does Debian replace our version of jetty with their own?

eyedeekay For the Debian package we un-bundle a bunch of stuff and use the Debian-provided alternatives yes

obscuratus Also, re i2p-bote, I'd been looking at that some. It's not good. It's way out of date. Doesn't know LS2, and that's non-trivial in i2p-bote.

obscuratus It might be time to EOL i2p-bote, and recommend any remaining users go with polistern's pboted.

eyedeekay polistern actually did a PR to update it to Bote v5, I'm going to try and trim away and update dependencies, maybe we can give it one more chance

obscuratus i2p-bote also has numerious dependencies, some very important, that need updating, and every one I looked at was very, very non-trivial.

eyedeekay That bad huh

obscuratus It was very daunting. :/

obscuratus For example, the bouncy castle encryption plugin has changed. You'd need to figure out how to update to the new API.

obscuratus Needless to say, encryption is tightly integrated into almost everything in i2p-bote, so updating the API changes will require a great deal of familiarization with the code base.

obscuratus Even though there may only be a few API changes that need to be addressed, this winds it's way throughout how i2p-bote operates.

obscuratus For better or worse, str4d depended heavily on a number of other projects to integrate into i2p-bote, and many of those have changed or even disappeared.

eyedeekay Sounds like you might be right, maybe the path for Java is to just run a pboted instance and connect to it with a client instead

obscuratus And, since the whole concept hinges on a DHT distribution of the messages based on the address, updating from DSA might be a challenge.

eyedeekay Assuming the goal of building a bote plugin

obscuratus Yeah, it might be easier to look to polistern's code, and re-build a new bote based on that, with fewer dependencies.

obscuratus Can you make a C++ project into a plugin? I had assumed no, but I should confirm that assumption.

eyedeekay You can sort of make it into a plugin, what you can do is wrap it in a "ShellService" which keeps track of the PID and optionally some information from the process it's hosting

eyedeekay Then the ShellService can wait until the router is ready for client tunnels to start the application, so it's like a plugin, but also works for things that aren't in JVM languages or even proper ClientApps

obscuratus Since pboted is SAM based, it might be just as easy to leave it as-is.

eyedeekay That's the idea with ShellServices, they're just unaltered applications who have their lifecycle managed by the router, setting it up is more-or-less just creating a client.config file in a plugin directory. They're basically intended for people to package SAM applications with

eyedeekay Limited utility for users familiar with managing services but for somebody who wants to just use bote as an application could be useful

dr|z3d re jetty, unless there's been a recent security update that supersedes what the console is running, then it's fine.

dr|z3d debian/repo installs use whatever the OS provides.

obscuratus Our current 9.3 jetty doesn't have any open security issues since that branch has EOL-ed. The 9.4 branch has a few security issues in the period since we last updated our 9.3 version.

dr|z3d afaik, wrt jetty/tomcat, jetty provides the webserver, tomcat handles the jsp compilation.

obscuratus So jetty is what renders our web console we all use?

dr|z3d jetty hosts the console and webapps.

dr|z3d re jetty 9.3 -> "So after four and a half years and 28 releases, the Jetty 9.3.x branch will be officially community EOL with the release of Jetty 10. It will still receive patches if a major security vulnerability is found, but aside from that will see no more releases."

dr|z3d it's been EOL for a good while now, but it still received security patches.

dr|z3d *receives

dr|z3d github.com/eclipse/jetty.project/commits/jetty-9.3.x

obscuratus HHhhhmmm, the jetty 9.3 branch hasn't had any commits since Oct. 2021. If I look at Jetty security vulnerabilities, there's been several since that last commit.

obscuratus github.com/eclipse/jetty.project/commits/jetty-9.3.x

obscuratus Oh wait, wrong link.

obscuratus eclipse.org/jetty/security_reports.php

RN do they apply to the 9.3 branch though?

eyedeekay The last one on that page listed for 9.3 does say it was discovered prior to October 2021 but I don't know for sure if that means that they don't apply or whether they were merely untested

dr|z3d we have the latest valid jetty 9.3 build.

dr|z3d any security issues and fixes are posted to eclipse.org/lists/jetty-announce/threads.html

obscuratus And they're talking about completely EOL-ing the 9.x branch in 2025. It might be time to start looking at migrating to a supported, current branch.

dr|z3d none of those reports relate to 9.30

obscuratus github.com/eclipse/jetty.project/issues/7958

dr|z3d it's still receiving security updates. that's good enough for now.

dr|z3d and the fact that it's not being actively developed can be considered a positive, given we don't need to follow the latest release cadence and update every time upstream does as would be the case with an active version. for now, at least.

RN on a much more pressing security issue. eyedeekay your auto-away has a pretty short timeout.

RN ;)

RN good points dr. Though do they indicate how soon the EOL hammer will drop?

dr|z3d not before 2025 before they abandon support altogether.

obscuratus They really seem like they're trying telegraph their lack of support for these branches.

dr|z3d they're gently nudging people to upgrade, sure, but if the version we're running was a real issue, it would have been a real issue before zzz departed. it wasn't.

eyedeekay getting a basically-working 9.48 build is easy enough, but it's received about 3 minutes of informal testing so far and is of dubious utility if all 9.x branches will be abandoned at once in 2025: git.idk.i2p/idk/i2p.i2p/-/tree/jetty-9.48-2022

dr|z3d there's a bunch of stuff in 9.4 that's useful for people running a fully-fledged jetty, and precious little for us.

obscuratus What version of Jetty is Debian using? Maybe they've already done the work for us.

eyedeekay 9.4.50-3 in sid 9.4.39-3+deb11u1 in stable

eyedeekay see 0002-jetty-compatibility.patch

eyedeekay rather: debian/patches/0002-jetty-compatibility.patch

RN so what are the challenges to moving to jetty 10?

RN is it reasonable to expect since there are two years to go, that it could be done low priority in one year?

obscuratus I see the min Java version for Jetty 10 is listed as Java 11.

eyedeekay I gather we update the library, fix the places where it fails to compile due to API changes, and extensively test all the webapps

dr|z3d that's the other thing, moving to jetty 9.4 required at least jetty 9 iirc?

dr|z3d *requires

obscuratus According the the d/l page, 9.4 works with 1.8

obscuratus eclipse.org/jetty/download.php

eyedeekay I'm pretty sure it's working with Java 8, I just built and updated using jetty 9.4 and java 8

dr|z3d ok, then I'm wrong on that one. I'm just trying to recall why zzz didn't feel the urge to make the leap to 9.4 when I suggested it a year or so ago.

eyedeekay Yeah me too, this has come up before and I remember him giving a reason

obscuratus Heh, this day has been like peeling back an onion.

obscuratus It looks like java 1.8 will mostly go EOL in 2026.

obscuratus Oddly enough it looks like Java 11 will go EOL in 2024. Maybe I'm not reading this correctly.

obscuratus I guess that means we'll need to revise all our build scripts since pak200 won't be available.

dr|z3d pack200 lives on in i2p+ :)

dr|z3d compatible with everything.

eyedeekay Yeah that's on the table, re: the oddity of 1.8 vs 1.11 EOL dates, according to what I've read it has to do with a change of policy which occurred at Java 10

eyedeekay This is handy: endoflife.date/java

obscuratus Interesting, that shows Java 8 support going through 2030.

RN I hope someone is taking notes. IRC discussions tend to cause memory corruption when pondering little deteails.

RN ;)

eyedeekay There are apparently several orgs that are supporting Java 8 through 2030, which isn't that surprising, some of them probably need it

eyedeekay According to wikipedia:

eyedeekay (OpenJDK currently maintained by Red Hat)[19]

eyedeekay March 2022 for Oracle (commercial)

eyedeekay December 2030 for Oracle (non-commercial)

eyedeekay December 2030 for Azul[12]

eyedeekay May 2026 for IBM Semeru[14]

eyedeekay At least May 2026 for Eclipse Adoptium[10]

eyedeekay At least May 2026 for Amazon Corretto[11]

eyedeekay It's going to be the next generation's COBOL