[HTHou]

Description

Upgrade the JLine bundle from 3.26.2 to 3.30.17 and synchronize its version in LICENSE-binary. The CLI, All, and Edge archives previously included jline-3.26.2.jar with the affected submodules. They now include jline-3.30.17.jar with the upstream fixes.

Published security fixes

Embedded artifact	Advisories	First fixed 3.x version
jline-remote-telnet	CVE-2026-56740, CVE-2026-56741	3.30.14
jline-reader	CVE-2026-77420	3.30.15
jline-builtins	CVE-2026-77421, CVE-2026-77422, CVE-2026-77423	3.30.15
jline-native	GHSA-6r3w-6jpj-x5w6	3.30.17
jline-remote-ssh	GHSA-7h86-pjwh-gpqj, GHSA-m935-wqpj-pvp3	3.30.17
jline-remote-telnet	GHSA-c87g-867h-cqr6	3.30.17

Validation

• Built the clean distribution reactor with mvn clean package -pl distribution -am -DskipTests on JDK 17.
• Passed all 80 CLI module unit tests.
• Verified archive checksums and license files. The All and Edge packages both contain JLine 3.30.17, with each embedded JLine version descriptor at 3.30.17.
• Started an extracted Edge package on macOS, ran SHOW VERSION from the packaged CLI in an interactive terminal, and verified that the CLI and Edge both stopped cleanly.

[CritasWang]

Thanks for the upgrade — versions/license are consistent and the CLI unit tests pass locally. However, this upgrade changes Ctrl+C behavior in the interactive CLI.

Since JLine 3.30.16, AbstractPty.PtyInputStream.read() treats a -1 returned in <50 ms as a real EOF (jline/jline3#1963, jline/jline3#2077). Pressing Ctrl+C makes the tty raise SIGINT and flush input, so the pending read returns quickly and LineReader.readLine often throws EndOfFileException instead of UserInterruptException. Cli.readerReadLine then exits right away instead of asking "Press CTRL+C again to exit, or press ENTER to continue".

Repro (driving JlineUtils.getLineReader through a pty on JDK 17/macOS, typing show ver then Ctrl+C, 10 runs each):

JLine	UserInterruptException	EndOfFileException
3.26.2	10	0
3.30.15	10	0
3.30.16	2	8
3.30.17	3	7

The jline-3.x branch still has this check, and only master/4.x moved to poll(2) (jline/jline3#2228), so a newer 3.x will not help yet.

Suggested fix: in Cli.readerReadLine, on EndOfFileException, check Thread.interrupted() first. In my runs it was true on every Ctrl+C-induced EOF and false on every real Ctrl+D, so this handles it as an interrupt (readLine(ctx)) and also clears the leftover interrupt flag. It may be worth reporting upstream as well.

[CritasWang]

Thanks for the quick fix. I re-verified on the new head (7653619): CLI module tests pass (82/82, with spotless/checkstyle). Driving the real Cli.readerReadLine with JLine 3.30.17 through a pty (JDK 17/macOS), Ctrl+C now always shows the exit confirmation: Ctrl+C → Enter → continue → Ctrl+D exits (6/6), Ctrl+C twice exits (3/3), and Ctrl+D on an empty line still exits without confirmation (3/3). Before this commit, about 7 in 10 Ctrl+C presses exited right away. LGTM.