IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/02/01
mesh is there something going on with the outproxies?
mesh literally can't reach everything. the entire system is coming down because the outproxies are just... not responding
mesh eyedeekay: it looks right...note also that purokishi.i2p also seems to be down
dr|z3d works for me.
mesh it's this problem again... going to purokishi.i2p works. (Albiet slowly.) Using 'purokishi.i2p' as an outproxy always fails. Going to exit.stormycloud.i2p works. Using 'exit.stormycloud.i2p' as an outproxy fails.
mesh (generally i2p services continue to work)
mesh I guess as a last resort let me try restarting the router. Tho really shouldn't have to
dr|z3d just restart your http client proxy tunnel
dr|z3d if you've been hammering the outproxies, you may have got your dest banned.
mesh hmm, restarting didn't help. cannot even access google.com
mesh I suppose I really should run my own outproxy. It's kinda my fault for having a critical external dependency
dr|z3d > just restart your http client proxy tunnel
dr|z3d > if you've been hammering the outproxies, you may have got your dest banned.
dr|z3d and if you have a fixed dest, restarting i2p won't help. make sure it's getting ditched.
mesh I wonder if that's it. Am I being treated as a hostile user because I have 8 inbound and outbound tunnels for the I2P HTTP Proxy
dr|z3d no, but if you're sending thousands of requests/m to the outproxies, then you will be treated as an abuser.
mesh is /tunnelmgr gone?
mesh hmm it's /i2ptunnelmgr now
mesh dr|z3d: you know I don't even see that option to persist destinations any more
mesh maybe it's not a thing for the http proxy
mesh dr|z3d: and it works. stopping and restarting the I2P HTTP Proxy service worked...
dr|z3d try not to abuse the services, then you won't have to do that.#
mesh dr|z3d: I can't be sending more than 50 requests an hour though I will add some logging to my systems
dr|z3d unlikely, mesh. the outproxy sees every request for a resource as a separate request. just visiting google will probably result in 20-40 requests.
dr|z3d you might just get unlucky when an outproxy is restarting, in which case a restart of the tunnel will pull a new lease.
mesh dr|z3d: I'm not actually browsing the web. I'm hitting an XML web service via the outproxy. It really is just one request sent less than a hundred times an hour. (Though I'm surprised the outproxy doesn't support request pipelining?)
dr|z3d http 1.1 is what the tunnel supports.
zzz eyedeekay, the bundles don't use the wrapper, correct?
eyedeekay They do not
zzz what are the last 4 errors? any help I can offer? (probably not)
eyedeekay 2 signature timestamp errors and 2 dylib sign errors, both on the same file, just mailed you the log
eyedeekay 2 errors, both of which are present on 2 different files, for a total of 4 that is
zzz which dylibs
eyedeekay Oh my mistake it's 4 errors on 4 dylibs now, libjvm, libjli, libjsig
eyedeekay 3 dylibs
eyedeekay The final list of errors should be on it's way to your inbox
zzz ok so not ours
eyedeekay Yeah and I've got a sneaky suspicion the solution is simpler than I think but no way to test it quickly
zzz I told you guys this would be hard, y'all didn't believe me ))
zzz are those libs imported as-is and already signed by somebody else (oracle?) or are you attempting to resign them yourself?
eyedeekay I was actually getting to where I think you're going
eyedeekay Working backward from zab's reasoning about signing/notarization and bugs in Java 14 and why he did the notarization this way in the first place it looks like it was related to a bug in the first version of jpackage where nothing was getting signed correctly at all
eyedeekay So in Java 14, they weren't signed correctly and zab re-signed them
eyedeekay But in Java 17 this bug is supposedly fixed and I don't think I need to re-sign them anymore
zzz so dump out the sigs
zzz are you resigning them or not right now?
eyedeekay Last erroneous notarization attempt they were re-signed, the next one they won't be
eyedeekay The current script re-signs everything that is to go in the DMG
zzz dump out the sigs and see if they include the secure timestamp from oracle
zzz if you were resigning them all, why did you have 3 timestamp errors but only one invalid ID error?
eyedeekay I don't know. My hypothesis was that I was signing the wrong type of artifact with the wrong type of keys so I tweaked the build script to sign each thing with what appeared to me to be the correct type of keys, according mostly to Apple forums and StackOverflow
eyedeekay When notarization reported fewer errors I kept the changes
eyedeekay We're doing this chess-by-mail testing strategy between me and echelon right now, if I could go faster I would figure it out by process of elimination
zzz you should be able to eyeball the sig data with some tool, without having to send it to apple
zzz and why do our files not have timestamp errors but the jvm libs do?
zzz so something's different about the 3 files
eyedeekay The thing that leapt out to me is the obvious one, they don't come from us, so my working hypothesis is that it's the re-signing causing the timestamp errors
zzz sure, but you should be able to verify that hypothesis with some sig-inspection tool
zzz you got 3 files with errors, and others without, take a peek
eyedeekay Just a min while I open up my mac workspace and figure out what that tool is for dylibs
zzz to be clear, I know nothing, but the more you can figure out locally, the less you have to shotgun it
eyedeekay Can't hurt to try it, you're absolutely right, and anything I can do locally I can iterate faster on
zzz in windows you just right-click to see the sig info
eyedeekay That'll do it lol. Just me over here looking for the hard way again :P
eyedeekay I'll find the terminal command later
zzz yeah whatever the CLI signing command is, there should be a verify flavor
eyedeekay According to my local environment nothing is starting out signed. I build the app image and run `find -name '*.dylib' -exec codesign -dv --verbose=4 {} \;` and all the dylibs are unsigned, but this is expressly a pre-DMG app bundle and not a DMG so I don't know what difference that might make
eyedeekay But maybe jpackage is re-signing the ones that would be signed by build.sh during the dmg generation phase...
eyedeekay I'll try that next
zzz yeah you said they weren't being modded, maybe not true, verify that
eyedeekay on line 154 and 155 the build.sh script signs the dylibs and the jnilibs as part of the Java 14 workaround I mentioned earlier, that's the only thing that happens to them as far as I know
eyedeekay Since removing those lines is the most embarassing answer to the question, I'm nearly sure it's that
eyedeekay j/k but I'm going to try it anyway
zzz point is, you can verify everything is signed right locally, you don't need apple to tell you that
eyedeekay The way the buildscript currently works is that if you don't set the signing properties then it stops short of signing anything, so I would expect to see either no signature or a signature provided by somebody else
eyedeekay Since I see no signatures at all I have other questions, such as:
eyedeekay does setting the signing properties in the jpackage command cause it to use signed versions?
eyedeekay or does it use the provided properties to sign the dylibs and jnilibs?
eyedeekay does Apple care who signs what?
eyedeekay I'm both speaking rhetorically and explaining what I'm trying to figure out, I can mostly figure out 1 and 2 without real keys but I still need to do the signing step explicitly
eyedeekay /keys/certs/
zzz no answers for you bubba, good luck
eyedeekay I'll get it figured out