IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/07/31
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cumlord
+poriori
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest22478
Irc2PGuest48042
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
acetone_
anon4
anu
boonst
juoQuua9
mareki2pb
not_bob_afk
plap
shiver_1
simprelay
solidx66
thetia
tr
u5657
weko_
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