@eyedeekay
&Irc2PGuest88200
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+eche|off
+hagen
+mareki2p
+orignal
+postman
+radakayot
+segfault
+snex
Arch2
Danny
DeltaOreo
FreeB
FreefallHeavens
Irc2PGuest53192
Irc2PGuest59134
Irc2PGuest59581
Irc2PGuest64993
Irc2PGuest69585
Irc2PGuest96449
Onn4l7h
Onn4|7h
Sisyphus
Sleepy
T3s|4_
aeiou
ardu
b3t4f4c3___
b4dab00m
bak83_
boonst
carried6590
cumlord
death
dr4wd3
duck
eyedeekay_bnc
not_bob_afk
onon_
phil1
phobos_
pisslord
poriori_
profetikla
qend-irc2p
rapidash
shiver_1
solidx66
thetia
u5657
uop23ip
w8rabbit
x74a6
orignal
zzz, what is your order of encryption keys in LS?
orignal
how they are listed in i2cp.leaseSetEncType?
zzz
orignal, I haven't tested it yet, but it's going to be hybrid-first. 5,4 or 6,4 or 7,4
orignal
what is user sets 4,5 and wants 4 over 5?
zzz
we honor published order preference. We'll use 4
orignal
so my question is
orignal
do they appear in this order in LS?
zzz
that is the LS2 specification. The order specifies preference.
orignal
thanks
zzz
the client can honor the preference, or not, but that's the way the server says what it wants
orignal
I care more about th opposite
orignal
when client connects what they prefer
orignal
see, you are a BOB
orignal
well never mind, you need to know it before you have LS
zzz
For alice, you can code it either way, client-preference or server-preference, or make it configurable. For bob, you set up the session with whatever type comes in
zzz
prop. 163 copied over to the spec: i2p-projekt.i2p/spec/datagrams
zzz
list of prometheus exporters: github.com/prometheus/docs/blob/main/content/docs/instrumenting/exporters.md
zzz
bitcoind, transmission, apache, nginx, squid, ...
zzz
we could add some for snark, i2ptunnel, etc
altonen
zzz there are some errors at the end of the page/sidebar: geti2p.net/spec/common-structures
dr|z3d
good stuff, zzz
zzz
thx altonen
zzz
altonen, you have an email address? Going to be sending out a reseed list update soon
altonen
thanks! you can send it to emissary@mail.i2p
zzz
ok. probably in about 3-4 weeks
zzz
fyi the new reseed will have a selfsigned cert, not letsencrypt, so I don't know if you want to deal with that
altonen
i think i can add self-signed certs
zzz
does the creativecowpat reseed work for you? it used to be selfsigned, we have a cert for it, but maybe he switched it
zzz
altonen, yeah it's still selfsigned, so you should either support that or remove it until you do
altonen
probably doesnt because i havent added the self-signed support yet, i'll need to chrck
zzz
ok orignal I've done my research on ratchet retransmissions, please restate your questions
zzz
I can already see the spec is a little light on details and might need some enhancements
zzz
perhaps altonen can also help in the discussion
altonen
hopefully
zzz
I haven't yet fixed whatever problems I have with PQ retransmissions but at least now I have my head in it
zzz
the most helpful to me was the HTTP GET picture under 'Typical Usage Patterns' but it's not quite enough, had to do some digging thru code
zzz
altonen, while I have you, I promised to review your inbound tunnel message handling/routing at the IBEP, but I looked around and couldn't really find the spot, can you point me in the right direction?
altonen
everything ibep-related is in this file: github.com/altonen/emissary/blob/master/emissary-core/src/tunnel/transit/inbound.rs
altonen
but if i get a free review from you, i'd rather wait until i've refactored the tunnel subsystem, i'm not very happy with it atm
zzz
transit? I'm asking about inbound on your tunnels, expl. and client
altonen
sorry, i got ibgw and ibep mixed up
zzz
I don't need GH links, just paths, I have the repo cloned here
altonen
tunnel/hop/inbound.rs is ibep, which routes the message to correct place using code from tunnel/pool/context.rs's route()
zzz
ok thanks that's helpful
zzz
actually route_message(), right?
altonen
yes
zzz
yeah that's what I was looking for
zzz
is that function/method (whatever rust calls it) a target for big refactoring or is it worth me staring at it? I think it's where the magic is, or needs to be
altonen
i'd say it's not worth your time, it'll go a big overhaul the whole system
altonen
just needs substantial "ass in chair" time which i haven't found yet
zzz
ok rather than a review let me just ask a couple questions that may get you thinking
zzz
looks like you have 3 different actions for 5 different msg types: garlic, the 3 DB msgs, and OTBRM. What's the default action? drop? handle? log?
altonen
drop
zzz
are you logging that?
altonen
i think so
zzz
good
zzz
what about after decrypting the garlics? do you go through the same or similar logic again checking the decrypted message type?
altonen
i think for expl. pool the garlic messages (not identified as TBRMs) are sent to netdb and for client pools to the destination
zzz
so you do make different decisions based on whether expl. or client, and on delivery instructions?
altonen
pool type, delivery instructions are not widely used
zzz
ok
zzz
that's my list of things to think about, because lots of messages down tunnels are dangerous if you respond to or even just handle them
altonen
responding i get but can you elaborate on handling?
zzz
our equivalent is InboundMessageDistributor, which isn't the prettiest code but does have a lot of comments in it
zzz
sure, ask
zzz
oh you want examples, right?
altonen
yes if you have an example
altonen
but i'll check the code & comments for that distributor
zzz
like you only want msgs down client tunnels to go to that destination, not another one, or to the router
zzz
do you have one big netdb or one for the router and for each client?
altonen
one router and then each destination has it's on "netdb", mainly just lease sets
altonen
but it does query floodfills from the main netdb
zzz
ok good, you're off to a good start, that took us 20 years to do that
altonen
i saw the cve and got paranoid
zzz
the cve was mostly baloney but it did push us to finish what we'd started
zzz
I guess databasestore is the main one where just acting on it could be a problem, but with database isolation you're in pretty good shape
altonen
that's good to hear
zzz
client netdbs can be LS-only, don't take RIs down client tunnels
altonen
i think they're rejected right now, no reason to have them there
RN
¿ baloney, or spam(tm) ?
RN
;)
zzz
dpm
zzz
don't take lookups down expl tunnels, or lookups down client tunnels except for your own LS, iirc
zzz
don't let somebody else store your own RI or LS to you
zzz
stuff like that
RN
y'all squashed that cve pretty hard! weather it actually could have been done or not. :)
altonen
thanks!
zzz
not an exhaustive list but our distributor code may be helpful
altonen
it's on my non-public todo list
zzz
I have an 'attack console' where I can send lookups and stores to specific routers and destinations and closest floodfills
zzz
end of free review ))
altonen
cheers
altonen
i was playing around with similar idea to that of the attack console, basically a programmable router that you could control via a scripting language during runtime
altonen
then you could write all kinds of nasty tests and see how a well-behaving router reacts
altonen
but haven't found time for that either