IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/07/31
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@not_bob
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Over
+Xeha
+acetone
+bak83
+cumlord
+hk
+onon_
+poriori
+profetikla
+r00tobo_BNC
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
Irc2PGuest53061
Irc2PGuest57148
Irc2PGuest60340
Meow
Nausicaa
Onn4l7h
Onn4|7h
anon3
anu3
boonst
cancername
carried6590
mareki2pb
plap
shiver_
simprelay
solidx66
thetia
u5657
eyedeekay I think that pretty much does it except for some UI issues
eyedeekay I have some qualms about my changes in ConfigKeyringHandler/Helper for handling blinding keys
eyedeekay And seeding the subdb's with less than 45 floodfills
eyedeekay But it all seems to work
eyedeekay And we only cascade across all netDb's for a lookup when we really mean to(stats output and the like) as far as I can tell
eyedeekay Encrypted LeaseSets are fixed although there is a de-facto shared context when managing the keyrings, some social engineering by a malicious operator could still link clients
eyedeekay But that's all way more far fetched than the stuff in acetone's blog post or that xeiaso was ranting about
eyedeekay Well impostor-xeiaso
eyedeekay It should make it magnitudes more difficult to design a novel attack
eyedeekay Oh also in RepublishLeaseSetJob I can't quite tell if I should send the republished LeaseSet out with the null dbid or just return, I'm leaning just return
obscuratus eyedeekay: Minor nested-netdb bug (or just apparent bug): When a client shuts down (I'm testing SAM clients that quit after a short period), the netdb for that client continues to persist when I pull of the NetDb or LeaseSet tabs, as if the netDb is still there after the client has gone away.
eyedeekay Oh damn good catch I missed that
eyedeekay Thanks, I'll figure out how to make that go away
eyedeekay I'm pretty sure that it's actually still there, they probably don't get shut down until the whole router shuts down
obscuratus That's what it looks like. I was poking around, but it's actually somewhat subtle exactly where a client dies in the code.
eyedeekay Yeah and honestly if it's not when the whole router is shut down then I'm not sure when to close out the subdb's is a question with a very clear answer... right now they actually persist on disk as well but I can turn that off
RN so this is when a client app doesn't exit cleanly? (crash, or not coding it to close them?)
eyedeekay No it's anytime a client exits at all, the sub-netDb that belongs to it sticks around
not_bob For about 10 min?
not_bob Also, what issues does this cause?
eyedeekay That's what I was thinking, does it matter and when, I don't think persisting the data leaks anything
eyedeekay But it does clutter the UI
eyedeekay Also maybe I'm wrong about it not being a leak, I would welcome the analysis
not_bob The only time I could see it causing an issue is if you shut down, restart your router and then have persistant keys.
not_bob I also may be wrong.
eyedeekay Yeah but if you have persistent keys then aren't your sessions already linkable? What are you giving away that you aren't by having the same b32?
not_bob *nod*
not_bob Which brings up the issue of multihoming.
eyedeekay But that does point out another issue though, *not* deleting the netDb's after a key rotates leaves them on the disk, so that's one answer
eyedeekay That needs to change
not_bob Multihoming works well enough, and it does magic load balancing as well. But, that's a side effect.
obscuratus Not a major bug, but if nothing else, it'll make it easier to evaluate how things are working without dead netDb's laying around.
not_bob Yeah, shouldbt they expire from the disk after a period of time?
eyedeekay I'll probably burn the ones from i2ptunnel as soon as the tunnels rekey
not_bob Perfect.
eyedeekay Others I think it remains to be seen