~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%acetone
%mareki2p
%snex
+Atticfire
+FreefallHeavens
+Onn4l7h
+Onn4|7h
+fa
+marek22k
+onon_
+profetikla
+qend-irc2p
+r00tobo
+sexy
+uop23ip
Arch
Danny
Irc2PGuest21708
Irc2PGuest28384
Irc2PGuest4937
Irc2PGuest66257
Irc2PGuest75631
Irc2PGuest99986
Over1
RTP_
Watson
ahiru
anontor
cims
i2potus
interesting
justaperson
lokzz
luvme3
mahlay
makoto
n2_
nilbog
not_bob_afk2
pinotto
poriori
r00tobo[2]
rednode
sahil
uberius
user_ygg2_
zzz
dr|z3d, re: your potential ratchet issue, I'm logging the whole package at WARN and haven't caught it.
zzz
you said you were hitting it 400x an hour? this was with the former error or with your "fix"?
dr|z3d
pre-fix iirc, zzz.
onon_
Have you really fixed the iirc disconnects?
zzz
ok dr|z3d I recommend you back out your fix which I've confirmed is harmful, then try to re-find the original symptom and we can go from there
dr|z3d
can you remind me of my commit, zzz, do you have that there?
zzz
commit ad983a3427fea75d266a14ba9cbc868caa2a38b9
zzz
Author: dr|z3d <z3d@i2pmail.org>
zzz
Date: Fri May 1 04:06:12 2026
zzz
Router: Fix NSR state race condition
dr|z3d
thanks
dr|z3d
so what's your assessment, zzz, we got an issue, or it's a non-issue?
dr|z3d
ok, re logging, with that "fix" in place I see ~700 in the current 10MB log
dr|z3d
> WARN [...Handler 6/6] ...et.RatchetTagSet: NSR state already consumed, rejecting tag 5SBTEZeTHXo= in TagSet #2199156 -> Possible duplicate or stale tag
zzz
my theory is that you've misremembered, you didn't ask your vibe machine to fix an issue, you sent it off looking for issues
zzz
until you come back with the original problem I'm unable to provide any other assessment
dr|z3d
actually, not entirely correct. I was looking at specific console warnings and potential issues.
dr|z3d
and as amusing as it may be, please stop referring to everything as vibes related. it displays a fundamental ignorance of the tech.
zzz
because I am ignorant, tell us what to call it
dr|z3d
llm-assisted agentic coding, or ai-augmented development are more accurate.
zzz
a little long and nonspecific )). It's not just you. rarely if ever does an AI bug report specify "the tech" and only about half the time even acknowledge that there is "tech"
dr|z3d
I gave you some links a while back thinking you might be curious enough to dip your toe in the water, see if the tools offer anything useful.
dr|z3d
yeah, you're not wrong there, the tech is polarizing right now, some people just hate in on principle. early days.
dr|z3d
*hate it
dr|z3d
if you want something shorter, agentic coding is probably about as snappy as it gets.
dr|z3d
interesting fact: 30% of Windows11 is now coded via LLMs.
zzz
whatever, we're back at the start, I'll await the "specific console warning" if you can reproduce it
dr|z3d
The issue was that there wasn't a specific warning pre-patch, it was just falling through and generating vague warnings.
zzz
ofc that's nothing actionable over here
dr|z3d
So I'm not convinced my patch is harmful as you're suggesting, it just catches the issue sooner and presents a more useful warning.
zzz
you still haven't defined "the issue". your "fix" violates the ratchet spec, and if you thought about it for 2 seconds you'd know that 700x/hr is not a race. Not going to waste more time arguing with you and your LLM-AAC/AI-AD
dr|z3d
the issue is re-use of ratchet tags, which are single-use. thanks for the analysis, I'll dig deeper and see if it's a non-issue or I can provide you with more substantive evidence.
dr|z3d
here's an in-depth analysis of the patch:
dr|z3d
Summary of Commit ad983a3427fea75d266a14ba9cbc868caa2a38b9
dr|z3d
Verdict: This patch is NOT harmful - it is a legitimate bug fix.
dr|z3d
What the commit does:
dr|z3d
The patch fixes a race condition in the NSR (New Session Request) state handling within the I2P Ratchet protocol's RatchetTagSet.java.
dr|z3d
The Issue:
dr|z3d
In the original code, when multiple tags from the same tagset attempted to use the NSR state concurrently, there was no protection against the same state being consumed multiple times. The NSR state is meant to be used once per tagset to establish a new session - reusing it would be a security concern.
dr|z3d
The Fix:
dr|z3d
1.
dr|z3d
Added a volatile boolean _nsrStateConsumed field to track whether the NSR state has been used
dr|z3d
2.
dr|z3d
Before using the NSR state in tagToSessionKeyAndNonce(), the code now:
dr|z3d
-
dr|z3d
Checks if _nsrStateConsumed is true → if so, logs a warning and returns null (rejecting the duplicate/stale tag)
dr|z3d
-
dr|z3d
If not consumed, sets _nsrStateConsumed = true before using the state
dr|z3d
Why it's not harmful:
dr|z3d
-
dr|z3d
The fix uses volatile for proper thread-safety
dr|z3d
-
dr|z3d
Returning null for already-consumed state is correct behavior - the caller handles rejected tags appropriately
dr|z3d
-
dr|z3d
It prevents potential cryptographic issues from key/nonce reuse
dr|z3d
-
dr|z3d
The warning log helps diagnose duplicate or stale tags in production
dr|z3d
This is a defensive security fix protecting against potential race conditions in concurrent cryptographic operations.
zzz
you sent me somethign similar 2 weeks ago. it's still wrong.
zzz
if you believe it, you should go try to fix the root cause, since your change admittedly just "cathes the issue sooner" but it's still happening 700x/hr
dr|z3d
ok, thanks for persisting, I'll have to rethink this one.
dr|z3d_
ok, should be fixed: github.com/I2PPlus/i2pplus/commit/22fd730fb38ed1feeb7f59636f29b58af9af53c3