Based on my current understanding of things, which I'm much more apt to trust than where I was at when this got checked in, we were mistaken and it's not an attack vector. I believe it is safe to…
OK, thanks for doing in-depth research on how we got here.
The reason I'm pushing is to make sure, based on today's understanding, that the code you removed (sending things received down a tunnel…
I checked in your fix on master but I'm not entirely satisfied that clienttps should be null so I'm leaving this open for now.
Line 56, clienttps can apparently return NULL. Proposed cannon fix (same as upstream save for logging string differences):
diff --git a/router/java/src/net/i2p/router/tunnel/InboundMessageDist…
In b0597e32b206aa0a14613b0cab3bc8e12e844e96 to be 2.6.1-3
Fix from Tunoac https://github.com/i2p/i2p.i2p/issues/81
On further research, it appears we don't have short timeouts for the headers; we set a 4 hour failsafe timeout and that's it, we rely on the browser to implement timeouts. I wonder what the…
Thanks for entering this ticket, because I don't think it's a new problem, I've definitely seen it, but it never quite reached the threshold in my mind that 'this is a bug we need to track down'.…
I see code in IRCFilter.java to allow I2CP ACTION in both directions, so that was the intent, perhaps it broke somewhere along the way, maybe by me...
If you're going to work on it please assign…