IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2025/03/06
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hagen
+hk
+lbt
+orignal
+postman
+segfault
+weko
+wodencafe
Arch
Danny
DeltaOreo
FreefallHeavens_
Irc2PGuest10722
Irc2PGuest16699
Irc2PGuest21882
Irc2PGuest27222
Irc2PGuest39482
Irc2PGuest59134
Irc2PGuest95432
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aeiou
aisle1
ardu
b3t4f4c3__
bak83_
boonst
bpb
cumlord
dickless
dr4wd3_
eyedeekay_bnc
poriori
profetikla
qend-irc2p
radakayot_
rapidash
shiver_
solidx66
thetia
u5657
uop23ip_
w8rabbit
x74a6
orignal zzz, about streaming signatures
orignal same idea as for datagrams
orignal if SYN comes through a ratchets session we might omit signature
zzz eyedeekay, good news, izpack 5.2.4 is out with the java 21+ fix. Please update and test your CI
zzz I'll be using it for the release
zzz eyedeekay, re: github.com/i2p/i2p.i2p/pull/100 - what is the issue you refer to that this fixes?
dr|z3d we use alpine latest in +, no reported issues.
dr|z3d (I'd far rather set and forget than have to keep updating version strings as new more suitable versions appear)
zzz OP said 'various issues', eyedeekay said 'the issue', neither elaborated
dr|z3d Don't you just love those :)
zzz OP said 'various issues', eyedeekay said 'the issue', neither elaborated
zzz eyedeekay, just looked at git.idk.i2p/i2p-hackers/i2p.firefox/-/issues , gave you a new one, and looks like you should go thru all the 2-year-old ones and close what you can
zzz orignal, re: streaming, yes, we discussed it briefly on tuesday
eyedeekay Sorry had errands to run this morning issue was related to outdated Java/libs in container, reports were in #i2p of the Docker container being unusable due to issues with Java 17 and mortbay. First noticed on TrueNAS then was observed on plain Docker. phil who has been helping with go-i2p recognized the issue and submitted the fix, I tested it.
zzz ok eyedeekay thanks. Did you triple-check that "temerin" and the download URLs he changed are legit, and we aren't getting supply-chain-hacked?
eyedeekay Yeah Termurin/the temurin container is legit it's what they changed the Eclipse OpenJDK distribution name to a few years ago
zzz ok great
zzz can you give me a short oneliner description of the issue for the upcoming release notes?
eyedeekay Updated outdated docker container and container libraries
zzz thx
eyedeekay And also probably credit urgentquest from Github
zzz don't usually give credit in roadmap or release notes but feel free to add it to history.txt
eyedeekay Will do
zzz I have my fingers in i2ptunnel today, seeing if I can generate a 5,4 LS2
zzz lets see what explodes
zzz 03/06 12:33:33.527 CRIT [nal Reader 4] 2p.data.i2cp.I2CPMessageReader: Uncaught I2CP error
zzz java.lang.IllegalArgumentException: Unsupported algorithm
zzz that didn't take long
zzz this is going to be messy
orignal zzz, that's for datagram not streaming
orignal for streaming I'm thinking to do it now
orignal just not verify SYN signature if from ratchets session
zzz we discussed streaming briefly also
orignal well I didn't ask my question yet )))
zzz <zzz>if we don't need 'from' or 'signature' any more, shouldn't we fix i2cp and streaming first?
orignal my question is
orignal is it possible to have stream on behalf of third party?
zzz please explain more
orignal someone sends SYN packet and LS that doesn't match ratchets static key
orignal so, they send LS and From matching that LS
orignal but it's from another destination, not the one for ratchets session
orignal that's the key question for next steps
zzz don't think so but would have to think about it more
orignal if we require LS matching session than we can filter LS-es first
orignal no unsolicited LS, but own
zzz this sounds very messy and hard
orignal another LS must be response to our lookup
orignal you got LS and check
orignal 1. Did we request it?
orignal 2. If we didn't, does it match sessions's static key
orignal very simple
zzz it's a big layering violation, smashing together two different protocol layers, and I have i2cp in between
orignal do we send peer-s LS though I2CP to client?
orignal I donb't remember that we do
zzz handling leasesets in ratchet
orignal then why two direrent levels?
zzz but as I said tuesday, there's no way to pass 'from' through i2cp
orignal we are talking about LeaseSets now
zzz yeah but if you strip the from and sig fields out of streaming then streaming doesn't know where it's from
orignal * [zzz] (zzz@5fweozxzwtgzln7sljuistexwqoias4iz3csub3jlnopxkubjaga.b32.i2p): zzz realname
orignal if you don't pass "From" through I2CP how this one works?
zzz in streaming. I mean separately
orignal no I don't want to strip From
orignal only signature
orignal because it's expesive
zzz then stop verifying
orignal that's what I'm going to do
orignal but I also want to stop signing
zzz I'm not recommending you stop verifying, but do what you want
orignal also you don't have "From" at rachets level anyway
orignal you have only static keys
orignal e.g. it might be many "From"s matching the same static key
zzz removing signing would be a big protocol change, I've added your idea to the list of proposals we're waiting for from you
zzz yeah the shared static key thing makes it harder
zzz aka subsessions
orignal why? it's just a flag
zzz but to not have huge PQ SYN packets you'd have to get rid of the From part also
orignal but you always have it like EdSA/DSA shared dest
orignal how long is PQ public key?
zzz yeah and I'm just starting on shared Ed/PQ dests type 5,4
zzz see proposal 169
orignal btw, why can't we pass B32 in From field?
orignal sice we are supposed to have peer's LS anyway?
zzz jrandom didn't have b32
orignal are you jrandom? me ethier
orignal why we can't change it?
zzz we can change anything we agree on, write a propsal
orignal I will do
orignal but mny question is maybe it was a reason for it
zzz since I'm not jrandom, I can't answer
orignal so you don't have any resons in mind
orignal I will write a proposal and amendment for Datagram2
orignal "use b32/b33 instaed full address"
orignal well b32 only, no b33 ofc
zzz no reason that I know of, before my time, but our git history goes back to April 2004 if you want to look around
zzz I think you mean binary hash, not b32
orignal sure 32-bytes SHA256
zzz working thru 5,4 issues to get tunnel tests working
orignal I remeber you had an issue with one time keys
zzz PQ + ECIES LS2
zzz a lot of unchecked exceptions, making it pretty easy to find issues and fix them
zzz think I got it kinda working
orignal I will join on 11-th
orignal opensl 3.5 alpha
zzz yup
zzz something's not right with tunnel builds
zzz this is going to be a while
zzz baby steps