IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/04/19
uop23ip Didn't work in the browser. Just weird text in falkon. firefox just blank. So did a vanilla (worked) install and used the update i2pplus.github.io/i2pupdate.zip. Worked got i2p+
uop23ip Then ddownloadedthe dev update. Worked
uop23ip Maybe there is something in the dev installer. At leastt for. Now i am on dev.
end50 Hello again, I wanted to ask about what happened to zzz.i2p and why can't I access it...
end50 The website seems to be down all the time.
end50 well, more like eepsite
tisratil7 hello everyone it's been a min
dr|z3d uop23ip: not sure where you were attempting to download 2.1.0+ installer from, on github.io the links are for 2.2.0+. but it sounds like you got it sorted eventually.
dr|z3d if a dev download fails from gitlab, it could mean that the build bot is in the process of building new files, happens sometimes.
T3s|4_ uop23ip: ^yep, normally a far outlier, but well within the realm of 'normal' experience :)
xeiaso So, it's been over 24 hours since issue 397 was discussed in IRC. What actions have been taken?
obscuratus Hey xeiaso, welcome back.
obscuratus I've been going through the code, trying to follow your assertions.
obscuratus Do you have any debugging patches you've added that would show this issue?
xeiaso You don't need debugging patches to read a single file.
obscuratus xeiaso: So, you've been examining the code. Did you come across a good place to address this?
obscuratus What message would they be sending us that would prompt us to reply back?
xeiaso Think of a HTTP server. When you send a GET request it sends back a reply.
obscuratus xeiaso: We talked about this yesterday. I still don't understand how a message can come down a tunnel, and the tunnel id variable is NULL. Can you explain what you're getting at there.
xeiaso The tunnel id variable is from an incoming packet. An adversary can decide to not include a tunnel id.
obscuratus I don't think we rely on them to tell us what tunnel they're coming down. We figure that out for ourselves, based on what tunnel we received the message through.
xeiaso >distribute(data, instructions.getRouter(), instructions.getTunnelId());
xeiaso line 376 directly contradicts that idea
obscuratus Ah, I had that backwards. The tunnel id is the target.
obscuratus So, the potentially worrisome line (as pointed out by you and in the lambdaplusjs thread) is:
obscuratus if ( (target == null) || ( (tunnel == null) && (_context.routerHash().equals(target) ) ) )
obscuratus in the inbound message distributor.
obscuratus I see tons of (target == null) && ( (tunnel == null)
obscuratus I've never seen a (target = <anything>) && (tunnel == null) in my logs.
xeiaso Looking the router hash while handling a destination-bound packet? It's definitely worrisome.
obscuratus How about I test this (for breakage). We'll normally process the (target == null) && (tunnel == null)
obscuratus I'll start dropping the (_context.routerHash().equals(target) ones, and print a great big warning.
obscuratus Then I'll monitor my logs, and see if that ever shows up.
xeiaso Sounds good, just make sure it doesn't break zero hop tunnels.
obscuratus I'll make it a critical error for testing. It should show up on start-up then.
obscuratus eyedeekay, dr|z3d: When you get a chance, please review my above conversation with xeiaso.
eyedeekay Already on it here thanks
RN "<xeiaso> So, it's been over 24 hours " ◀━━ wow! Bossy much?
RN being pushy and entitled won't make things move any faster
RN the issue is most likely bogus misunderstanding of the code, but it is being investigated seriously.
xeiaso Entitled? I don't run Java I2P. I have no stake in the outcome.
RN but you come in demanding answers