#i2p-dev (irc2p) | 2.10.0-3 | See important notes on zzz.i2p before updating

orignal zzz, is PQ applied to single racthets messages withut static key?

orignal btw, I have implemented 6 and 7 for Bob

zzz repost from wednesday:

zzz <zzz> ok orignal I've done my research on ratchet retransmissions, please restate your questions

zzz <zzz> I can already see the spec is a little light on details and might need some enhancements

zzz <zzz> the most helpful to me was the HTTP GET picture under 'Typical Usage Patterns' but it's not quite enough, had to do some digging thru code

orignal what are you talking about?

orignal NSR?

zzz yeah you had some questions two weeks ago, I said hold off, you reminded me early this week, and now I'm ready ))

orignal yes, I was asking when do we drop ephemral keys on Alice side

zzz I had a question also while I was debugging, because it seemed like you switched from NSR to ES before you got an ES from me

zzz on the Alice side, you drop the handshake state when you get the NSR

zzz on the Bob side, you can't drop the handshake state until you get the first ES

zzz on the Bob side, are you sending ES before you get an ES from Alice?

orignal on Bob side it's clear

orignal but only Alice side I don't know how many more NSR might come

orignal what is ES?

orignal Bob keep sending NSR until receives first message from Alice

orignal even is he starts sending regular message there are few NSR on the way

zzz ES = existing session message

zzz when I had bugs and was failing to decrypt NSR, I was also getting small messages that looked like ES

zzz on the Alice side, once you get one NSR, you can throw out all the handshake states, you don't need to decrypt the additional NSRs

orignal no I don't send ES until I get NSR back

orignal how come I don't?

orignal they might contain vauable payload

zzz true. Maybe I do save them, I'll have to look

orignal if I send ES before NSR sure it's a bug I will check the code

orignal back to zero static key in NS

zzz no I mean on the bob side, sending ES before you get the first ES from Alice

zzz this all definitely needs a new section in the spec, it's not well-documented

orignal if pq section is requeried can we fill it with all zeros?

zzz huh? what message?

orignal ohh you mean short messages from my Bob?

orignal that's bug I have fixed yesterday

orignal you can send "one-time" NS

zzz yes it looks like you were sending ES as Bob when I crapped out on the NSR as Alice

orignal right?

orignal when static key is all zeros

zzz yeah the "one-time" format is in the spec, do we use it? I forget

orignal I don't know

orignal I just see it in the code

orignal I guess we can fill that section will all zeros too

zzz I don't remember much about it, will have to research

orignal no worse to generate PQ keys anyway

orignal since we don't expect reply

orignal *worth

zzz right, if it's one-way, there's no KEM agreement possible

orignal but since Bob doesn't know if static key is all zeros

orignal we must add pq section as usual

zzz hmm

zzz will research, remind me next week

orignal anotther question that I asked before

orignal but came again

orignal can we assume that LS coming from racthets session must contain it's static key?

orignal and if not it gets dropped

zzz that's not what I do

orignal I know, but can we assume it

orignal ?

zzz if there's no LS with a key, I treat it as 'unvalidated'

orignal there is a LS with a key but key is different from session it came from

lbt Hey! I noticed my blog isn't reachable anymore (503). In the logs I see JettyStart CRITing, complaingin about: Attribute value "Server" of type ID must be unique within the document.

zzz my 'validation' checks for a key of the correct type and that it matches the key in the NS

lbt Now I didn't change anything in the config for years. Also ad hoc I didn't find any multiple declarations. Any hints?

zzz lbt check your .i2p/eepsite/jetty.xml file

orignal so you check it

lbt Ya, looking into that. But as I didn't change anything, I figured it's worth mentioning "it just went broke" to you anyway ;)

zzz yes orignal

orignal thats' what I was asking

orignal will do the same

lbt It's in /var/lib/i2p/i2p-config/eepsite/jetty.xml though (debian with system-wide install)

zzz lbt try starting again on /configclients

zzz oy debian. maybe jetty got updated and now is not happy? what's your jetty version?

zzz server version on logs page

lbt Starting again looks like same thing happening. Server version:9.4.57.v20241219

zzz github.com/jetty/jetty.project/issues/12881

zzz whats your java version, looks like it might be an underlying XML issue

lbt OpenJDK 64-Bit Server VM (build 17.0.14+7-Debian-1deb12u1, mixed mode, sharing)

zzz try this. in ALL the xml files jetty.xml, jetty-ssl.xml, jetty-rewrite.xml, jetty-jmx.xml :

zzz try change <Ref id="Server"> to <Ref refid="Server">

zzz did the error point to a line/column number in the XML, and was it the Ref line?

lbt It did - and ya it was referencing the closing ">" of Ref id="Server" I think

lbt I know tried 1,$s/Ref id=/Ref refid=/g in all the xml files. Still doesn't start, but changed the error given. I think the relevant part might be: Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.server.Server

zzz not sure if it's <Configure> and <Ref> with the same ID in one file, or if it's cross-file <Configure>s with the same ID

zzz as usual the jetty devs are totally unhelpful in that ticket. 'unsupported, please pay us'

lbt Well, it sounds like Debian stable has a years old version there, so not sure how much to blame they are ;)

zzz we bundle 9.3 but in Deb we depend on 9.4, both are ancient, but it's the last one supported on Java 8

lbt iirc I can setup an apache and use that to serve the files - that would probably circumvent this problem, or?

zzz ofc, but it doesn't help us fix it for anybody else

lbt Ya ;) I also liked running the build-in/proposed variation and it ran stable for so many years now :)

zzz looks like two of the files have configure.dtd at the top and two of them have configure_9_0.dtd

zzz try changing the two of them to 9_0, and if that doesn't work, try changing all of them to 9_3

zzz keep the refid change

lbt In my case they were all without a version number it seems

zzz ok, depends how long ago you installed

zzz stackoverflow.com/questions/33534308/must-id-attributes-be-unique-in-xml

zzz wait

zzz I think you did too much with your global replace

zzz only replace the ones where id="Server"

lbt Ok

zzz I only see two, one in jetty.xml and one in jetty-ssl.xml

lbt Ok, so I replaced the xml files with the ones I backed up and used 1,$s/Ref id="Server"/Ref refid="Server"/g

lbt However, now it complains about Caused by: org.xml.sax.SAXParseException; lineNumber: 233; columnNumber: 34; Attribute value "Contexts" of type ID must be unique within the document.

lbt Which is ... <Ref id="Contexts" />

zzz ok fix that one too

zzz actually maybe you were right, they all need to be chaned

lbt Did that, next one is <Ref id="DeploymentManager">

zzz so why are you getting the class not found error?

zzz I guess go back and change all the Refs, and go back to trying the DTD change

lbt No idea tbh. Let me check how many complains it gives - next was another one with DeploymentManager

zzz I just looked in the jetty source, and all their default xml files have <Ref refid="..."> for everything. So I think that's right

lbt Then <Ref id="RequestLog"> - after that I start getting the classNotFound again

zzz hmm

lbt This is with all at configure.dtd as they were

zzz paste us the class not found stack trace on cake.i2p

zzz and go ahead and change the rest of the <Ref>s

lbt cake.i2p/file/cW9HNrH7XO_Xzhar1MXwlsTCaYq1JPeFsHPtWFX8V_6G7TLxTSJH/i2p-stack.txt

zzz nothing remarkable there

zzz try changing the DTDs

lbt I did. And also did the replacing in the other 3 files now (changing 4,1,1 occurences). Stacktrace stays the same it seems

zzz I'm stumped on the class not found issue. I'm convinced that changing all the <Ref id to <Ref refid is correct

lbt It might just check them in this order, i.e. we didn't introduce that by the changes but are only seeing it now as the other complaints are out of the way, right?

lbt But ya, feels like missing something basic. I have a dejavu about having something like this with a java project long ago though ;)

lbt jetty.xml mentions docs.codehaus.org/display/JETTY/jetty.xml - but that domain doesn't seem to exist anymore? Might be my Tor though, of course ;)

zzz since it died when you changed the RequestLog Ref, try this to go back to the standard jetty request log:

zzz - <New id="RequestLogImpl" class="org.mortbay.http.I2PRequestLog">

zzz + <New id="RequestLogImpl" class="net.i2p.jetty.I2PRequestLog">

zzz ^^ actually the reverse of that

zzz no wait, that's not right

zzz hold on

zzz ok

zzz change net.i2p.jetty.I2PRequestLog to org.eclipse.jetty.server.NCSARequestLog

zzz AND

zzz xml-comment-out  the <Set name="b64"... line below it

lbt No such name here, only filename/filenameDateFormat/retainDays/append/extended/logCookies/LogTimeZone

lbt And just changing the class doesn't change the CnF

zzz ok you have a really old install, you've been around a while

lbt Hopefully not a bad thing in general ;) Shall I pull the current version of the file and try with that?

zzz might get messy because the file gets fixed up on first install

zzz it's strange because of course the server is found or your console wouldn't work

zzz oracular is on 9.4.55, and plucky coming out shortly will be 9.4.56

zzz I don't see anything in the changelogs about this kind of stuff

zzz can you try switching to java 8?

zzz did you first install before 2009? maybe your wrapper.config classpath?

zzz I'm really grasping here

zzz I can try to test with the 9.4.55 jetty here on my ubuntu but that may or may not have the issue

lbt Hm, is there a good way to determine when the install (machine/i2p) was by looking on the system?

zzz actually, debian should update wrapper.config for you

lbt I did migrate the virtual machine to a new hypervisor in 2015 but it seems I first installed the VM back in 2012

zzz in /etc/i2p/wraper.config, do you have wrapper.java.classpath.1=/usr/share/i2p/lib/*.jar ??

lbt ya

zzz ok then my last suggestion is trying java 8, but I'm not hopeful.

lbt As in not-openjdk-java?

zzz I can try to reproduce here with ubuntu and 9.4.55, and then again in a couple weeks on plucky with .56

zzz no, openjdk is fine, just use update-alternatives to switch to 8 (install it if you don't have it)

lbt What version of openjdk are you referring to with java8 - you don't mean openjdk-8, or? stable has -11 and -17 in its repos

zzz oh wow debian doesn't do 8 anymore? didn't know that. try 11 then

zzz but I'm not hopeful

lbt Seems to work, though ;)

zzz no shit

lbt Empty log and blog is reachable again, so ya

zzz super, we got you going, but I have work to do

zzz would you please paste the original stack trace about the duplicate ID?

lbt Are the old logs kept somewhere or do I need to reproduce?

zzz should be in the wrapper log file

lbt Right, system logs ;) Do you want that on cake.i2p or where?

lbt cake.i2p/file/WnlpM8Kbw0_PqtiKpv5XuCJMwHZRLglcP1QkbJsYt_0vhP51m8Dm/i2p-stack.txt

lbt Does that contain all you need? Otherwise let me know. Also it will be gone from there in an hour ;)

lbt And thank you very much for the help!

zzz got it, perfect

zzz and one last quick test if you could, change all the refids back to ids, to see if Java 11 alone fixes it, or we need both

lbt I copied back the xml files from the backup and stopped/restarted the eepsite which let to the non-unique error again

zzz super, thanks, so we need both refid and java 11

zzz still researching, and started on an xml file migration tool that we'll run automatically on upgrade

zzz could not reproduce here on java 17.0.14+7 and jetty 9.3.x

lbt Uh, strange. I did this by just restarting the eepsite (not the whole router). Now I copied the modified xml files there again, but attempting to restart now yields the CnF again? I might have messed something up, let me check ...

lbt Restarted the router now and it works again. So I guess there was some kind of caching involved?

zzz there might be some classloader jank when stopping/restarting client applications