~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@orignal
@postman
@zzz
%Liorar
%acetone
+FreefallHeavens
+Onn4l7h
+Sh0ck
+bak83_
+bpb
+leopold
+r00tobo_BNC
+uop23ip
+xHarr
Arch
BubbRubb
Danny
DeltaOreo
H20
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest97218
Maylay
Meow
ac9f_
anontor
b4dab00m
eyedeekay_
halloy13412
john231
makoto
nZDoYBkF
nilbog-
not_bob_afk
ntty
poriori_
profetik1
r00tobo[2]
shiver_
simprelay
solidx66
thetia
tr
u5657
vivid_reader56
zer0bitz
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