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
eyedeekay
Did you check for this: zzz.i2p/topics/3547-java-i2p-incorrect-ssl-outproxy
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