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.
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
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
Oh wait, wrong link.
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
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
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