mesh
am I the only one having a bunch of trouble reaching postman these days?
RN
no
RN
there is an issue with certain dests
RN
something to do with old vs new crypto migration from a while back
RN
mostly keep retrying
mesh
RN: ok well I take some small comfort in the fact that others share my suffering
not_bob
I too have had issues getting him on the line.
not_bob
I've been having issues wtih mail.
dr|z3d
No is the answer, re sharing ips between i2p outproxy and tor exits.
Opicaak
Thanks, doc.
eyedeekay
At last I fixed it. The fix for the key confusion issues is on this MR i2pgit.org/i2p-hackers/i2p.i2p/-/merge_requests/120
dr|z3d
what did you fix, eyedeekay?
dr|z3d
Opicaak: when setting up stormycloud's outproxies, I made sure we weren't using Tor ips. Cloudflare is a nuisance.
eyedeekay
The thing that's breaking Postman's services, "Unsupported Encryption Type"
dr|z3d
Oh, well done :)
eyedeekay
It's now no longer possible to accidentally pick up a wrong subDb
eyedeekay
Bunch of other things went along with it too, the memory management and concurrency issues most notably
Opicaak
dr|z3d, great thinking, I assumed it wasn't sharing them, but wanted to be extra sure.
dr|z3d
concurrency I think is what's breaking my flags. did you do away with most of the synchronized calls that were introduced?
eyedeekay
Yeah now the subDb's are initialized ahead of time in the ClientConnectionRunner and the FNDS calls are just reaching into the CCR to get the FNDS inside of it
eyedeekay
No more stacking them all in the FNDS
dr|z3d
smells like progress :)
eyedeekay
Yeah it's getting there, problems and uncertainties are gradually falling away
RN
are these changes worth a build at this point?
dr|z3d
they're sitting in the merge requests tray right now, no, eyedeekay? in which case you'll have to wait.
eyedeekay
I would definitely say they're worth building if you want to try them out, everything works as it should and any further changes will probably be subtractive, but I've left them in the MR for the time being because it's a big plumbing change
eyedeekay
There's a merge conflict though so it may be more trouble than it's worth
dr|z3d
RN: any time you hear the words merge conflict, run in the opposite direction.
eyedeekay
It's gone now
eyedeekay
dr|zed do you happen to know if it's possible to configure a proxy that is applied to requests initiated by a war `.war` started by jetty? My case is a git server which supports importing from a remote git server, which can be invoked from the web interface
eyedeekay
I want to prevent a user with an account on the git server from importing a git repo from a clearnet server that they own without using a proxy
dr|z3d
you'll have to rephrase the question, eyedeekay, I don't understand what you're trying to prohibit :)
dr|z3d
If I understand correctly, you want to prevent direct imports from remote git servers to your server, you want to enforce importing via a proxy. I doubt that's possible.
dr|z3d
You might, otoh, be able to enforce using a proxy at the server end of the deal to import the repo.
eyedeekay
Exactly, that would make things easier for this: eyedeekay.github.io/Gitbucket-over-I2P-Tutorial
dr|z3d
Just enforce a proxy server side.
eyedeekay
Now I don't think I understand your answer
eyedeekay
If server A is the one importing and server B is the one hosting the repo to be imported, where does the proxy get set up, bearing in mind that hypothetical attacker is the owner of server B?
dr|z3d
you pipe all imports through a proxy of your choice, no?
eyedeekay
No that's precisely what I'm trying to figure out how to do, but specifically from a `.war` placed in `~/.i2p/eepsite/webapps/` for instance
eyedeekay
Like for instance is it possible to set System.setProperty("http.proxyPort", "4444") for all such `.war`'s
dr|z3d
here's an entirely different proposal. don't run an open github service on i2p. authorized users only.
eyedeekay
That's what the defaults give you anyway, at least with gitbucket
eyedeekay
If I have to I'll leave it thus, really just a matter of interest
eyedeekay
It would also be useful for anything that federates like activitypub
dr|z3d
this enforces a proxy for all war files you'd need to modify it to handle specific war files, but the main part is the ProxySelector method:
dr|z3d
/ Set up the proxy host and port
dr|z3d
String proxyHost = "proxy.example.com";
dr|z3d
int proxyPort = 8080;
dr|z3d
/ Create a Proxy object using the specified host and port
dr|z3d
Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(proxyHost, proxyPort));
dr|z3d
/ Set the default proxy for all connections
dr|z3d
ProxySelector.setDefault(new ProxySelector() {
dr|z3d
@Override
dr|z3d
public List<Proxy> select(URI uri) {
dr|z3d
return Collections.singletonList(proxy);
dr|z3d
}
dr|z3d
@Override
dr|z3d
public void connectFailed(URI uri, SocketAddress sa, IOException ioe) {
dr|z3d
// Handle connection failure if required
dr|z3d
}
dr|z3d
});
dr|z3d
not all war files, sorry, the jvm they're running under.
eyedeekay
That would end up applying to the JVM that I2P is running under as well right?
dr|z3d
it would. you'd need to tweak it to handle just the wars you're interested in proxying.
eyedeekay
That's what I thought, could be a start though
eyedeekay
Not the time right now but when I finally have the time to experiment seriously with alternatives to gitlab that will be helpful, thanks
dr|z3d
that's a method for handling a specific war file.
eyedeekay
*that's* what I need
eyedeekay
Thanks
dr|z3d
*thumbs up*
dr|z3d
eyedeekay: as for alternatives to gitlab, gitea is all you need. it supporting importing and mirroring repos, can work with existing github/gitlab repos, and doesn't require a huge amount of resources to run.
eyedeekay
Oh for my main instance I **will** be using gitea when I get the chance
eyedeekay
I'm just... committedly anti-monoculture
eyedeekay
And gitbucket being Servlet 3.0 makes it super convenient to host on Java I2P obviously, so if you're not a Go nerd but want to host a git server over I2P it makes a somewhat interesting choice IMO
eyedeekay
The way you solve the same problem I had with gitbucket is also the second goSam example
eyedeekay
to accomplish it with gitea
RN
didn't read all that... but will. at a glance wounds like just build after a 'bump'
RN
s/wounds/sounds/
dr|z3d
you've got things to do, RN...
dr|z3d
they'll write a book about you one day. "How to motivate a slug".
RN
LOL
RN
I do have to enforce priorities I do not like right now
RN
but I will get back to what you are hinting at soon
RN
before that or further chat... I do want to finish with reading the scrollback.
RN
and a "show" I am co-watching with a friend... so be just a bit
RN
durring adverts I listen to the scrollback
RN
unless my mobile goes off with a call or text from friend co-watching
RN
LOL
RN
not as complicated as it sounds, after reading what I typed. lol... but a bit more to catch up and now the commercials are off again
RN
I think about slug, and can't help but picutre the telephone from the live action version of OnePiece
RN
the one with the moustache
RN
ok yeah that was a lot
RN
Σ:Đ
RN
not a lot of words, but a lot to digest
dr|z3d
do first, think later :)
zzz
eyedeekay, dr|z3d, the http.proxyHost and related config looks like JVM catnip magic but they are ancient things that don't work on NIO
zzz
See TransportManager.isProxied() where we detect and warn people foolish enough to try
dr|z3d
you mean the example I pasted in channel, or the example I pasted to cake?
dr|z3d
the cake example was using some apache classes to do the magic, but alas cake has been eaten.
zzz
didn't closely review either, but in general there's no JVM-wide facility/setting that works on NIO
zzz
some settings do affect some things (and could break things like UPnP), so that code is there to warn people that think they can proxy all i2p traffic with a quick setting. They can't
zzz
the full suite of things that don't work:
zzz
TransportManager.java: private static final String PROP_JAVA_PROXY1 = "socksProxyHost";
zzz
TransportManager.java: private static final String PROP_JAVA_PROXY2 = "java.net.useSystemProxies";
zzz
TransportManager.java: private static final String PROP_JAVA_PROXY3 = "http.proxyHost";
zzz
TransportManager.java: private static final String PROP_JAVA_PROXY4 = "https.proxyHost";
zzz
re: MR 120, yes it's the one we're waiting for, no I don't think it's ready
dr|z3d
is it heading in the right direction?
dr|z3d
also, speaking of directions, where did Obscuratus go? Maybe you scared him away? :)
zzz
I see some one step forward, two steps back that I don't understand atm
zzz
we'd be better off with Obscuratus help, dunno
zzz
my current headscratcher is ClientConnectionRunner. I thought I contributed a turnkey perfect solution, idk agreed and took it, but a few days later rewrote it and made it much worse?
zzz
but ofc I wasnt doing any testing so who knows
dr|z3d
it sounds like you need to be a bit more handsy in your approach right now :)
zzz
I'm handwaving all I can :)
dr|z3d
I mean hands on, not hand wave :)
zzz
trying to avoid Pottery Barn rules for now
dr|z3d
so what are you up to on the side?
zzz
working thru my wip/todo list from Feb
zzz
almost done playing with JCE ChaCha, pretty sure it won't be worth it
zzz
something like 99% of the calls are too small to benefit
zzz
even with java 21 + AVX
dr|z3d
well, it sounds like you're almost ready to push it out, is there any downside aside from the time invested?
zzz
what do you mean push it out?
dr|z3d
push it to trunk, or that's not the plan?
zzz
it's slower 99% of the time, so then we have to add a length check to avoid it 99% of the time, so it's really not worth it
dr|z3d
find another toy in that case. best advice. :)
dr|z3d
what about http/2, or you're still mulling over persistent connections?
zzz
the most I'd think of checking in is a commented-out main() speed test code
zzz
also, I did all my mods in the chacha-only code, but all those are with super short data; the only place that would benefit is chacha/poly where the sizes are much bigger
zzz
but that's completely different, harder, riskier
zzz
still thinking about it
zzz
atm it seems like a risky 6 month project in two stages, where the first stage (client side) provides no speedup at all, it's only prep
zzz
the second stage would be the i2p socket
zzz
and the server side would be the 3rd stage but I don't think it's necessary at all
zzz
a lot of the other toys on my list are blocked by the tsunami