chore(deps): upgrade ratatui to 0.30 (RUSTSEC-2026-0253) - #2589
Open
1688mengdie wants to merge 3 commits into
Open
chore(deps): upgrade ratatui to 0.30 (RUSTSEC-2026-0253)#25891688mengdie wants to merge 3 commits into
1688mengdie wants to merge 3 commits into
Conversation
The locked lru 0.12.5 pulled in by ratatui 0.29 is unsound (RUSTSEC-2026-0253, later advisories reference RUSTSEC-2026-0002): LruCache::pop is not panic-safe, and eviction can cause a use-after-free or double free. The advisory requires lru >= 0.18.2, which ratatui 0.29 cannot satisfy because it pins lru ^0.12. Upgrade ratatui 0.29 -> 0.30 (ratatui-core 0.1.2 requires lru ^0.18, resolving lru to 0.18.2) and relax the bitflags pin from =2.11.1 to ^2, which ratatui-core 0.1.2 needs. ratatui 0.30 adds an associated Error type to the Backend trait, so the CLI startup loop now carries an explicit `B::Error: Send + Sync + 'static` bound. Only the CLI TUI startup path consumes this API. Test: cargo check --locked -p bitfun-cli --jobs 4; cargo tree --locked -i lru --depth 1; cargo test -p bitfun-cli --jobs 4; cargo fmt --check AI: lightly tested
The ratatui 0.30 upgrade (2cdc3b2) left two crossterm versions in the lockfile: the CLI kept a direct crossterm 0.28 dependency while ratatui-crossterm 0.1.2 pulls crossterm 0.29. The split also changed the cursor-position path on unix: ratatui 0.30's draw pipeline queries the cursor position through crossterm 0.29, which sends a CSI 6n device status report and blocks until the terminal answers. Inside the PTY test harness no terminal emulator answers the report, so the startup draw failed with "The cursor position could not be read within a normal duration" and the interactive TUI exited before rendering its first prompt. Windows passed because its cursor path uses the console API instead of the 6n round-trip, and the headless exec tests passed because they never draw. Unify the CLI on crossterm 0.29 so the direct dependency and the ratatui-crossterm adapter share one version. The CLI only uses the event and terminal modules, which are API-compatible between 0.28 and 0.29, so no source changes are required. cargo tree now resolves a single crossterm 0.29.0 for both the CLI input path and the ratatui backend, keeping the event-loop and cursor state in one instance. Test: cargo check --locked -p bitfun-cli --jobs 4; cargo test -p bitfun-cli --jobs 4; cargo tree --locked -i crossterm --depth 3 AI: lightly tested
The ratatui 0.30 upgrade (2cdc3b2) made `Terminal::clear` snapshot and restore the cursor position around the screen clear, and the startup page clears the terminal right after rendering the loading placeholder. On unix this reaches `crossterm::cursor::position`, which writes a CSI 6n device status report and blocks until the terminal answers; the previous ratatui 0.29 clear never queried the backend. Inside the PTY test harness no terminal emulator is attached, so the query went unanswered and the CLI exited with "The cursor position could not be read within a normal duration" before rendering its first prompt. Windows kept passing because its cursor path uses the console API instead of the 6n round-trip, and the headless exec tests kept passing because they never draw. Unifying crossterm at 0.29 (da74153) removed the dual-instance split but could not remove the 6n round-trip itself, so the ubuntu and macos failures reproduced unchanged. Teach the PTY harness to act as the missing terminal emulator: the existing reader loop now scans the CLI output for the 6n query and answers it on the master side with a well-formed cursor position report. The report value is arbitrary because the CLI clears the screen and every draw emits explicit cursor movement afterwards. The writer handle is shared through an Arc<Mutex<>> between the reply path and the test input path since portable-pty allows taking the writer only once, and a short tail of each scanned chunk is carried over so a query split across read boundaries is still answered. The harness change is test-only and touches no production code. Test: cargo check --locked -p bitfun-cli --jobs 4; cargo test -p bitfun-cli --jobs 4 --test terminal_process_contracts; cargo fmt --check AI: lightly tested
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cargo auditreports the lockedlrudependency as unsound:RUSTSEC-2026-0253 (later advisories reference RUSTSEC-2026-0002).
LruCache::popis not panic-safe; when an eviction happens while apanic is unwinding, the cache can be left inconsistent, leading to a
use-after-free or double free.
Cargo.lockonmainpinslru 0.12.5through
ratatui 0.29.0, and the advisory requireslru >= 0.18.2,which
ratatui 0.29cannot satisfy because it pinslru ^0.12.On the CLI TUI startup path,
ratatuirenders the interactiveinterface; a panic during eviction on that path could trigger the
unsound behavior.
This PR upgrades
ratatuifrom 0.29 to 0.30:ratatui-core 0.1.2requires
lru ^0.18, which resolveslruto 0.18.2 and closes theadvisory. The upgrade requires two mechanical follow-ups, included in
the same commit because the intermediate states do not compile: the
bitflagspin is relaxed from=2.11.1to^2as required byratatui-core 0.1.2, and the CLI startup loop carries an explicitB::Error: Send + Sync + 'staticbound for the new associatedErrortype on the
Backendtrait. Only the CLI TUI startup path consumesthis API.
Fixes #2587
Type and Areas
Type: dependency
Areas: CLI TUI dependency
Verification
cargo check --locked -p bitfun-cli --jobs 4— passed (0 errors; 19 pre-existing warnings unchanged).cargo tree --locked -i lru --depth 1— resolvedlru v0.18.2throughratatui-core v0.1.2;cargo tree --locked -i ratatuishowsratatui v0.30.2consumed by the CLI.cargo test -p bitfun-cli --jobs 4— 685 lib tests passed; 3 pre-existing failures (plugin_source_cli) are identical on the baseline commit (same names, same panic locations), so they are unrelated to this change.cargo fmt --check -p bitfun-cli— one pre-existing diff inpeer_host/commands/dialog.rs, byte-identical on the baseline commit; no formatting change from this PR.Reviewer Notes
ratatui0.30 is the first 0.30.x release line; the lockfile resolves it to 0.30.2 andlruto exactly 0.18.2 (the advisory's minimum fixed version).src/apps/cli/src/ui/startup.rs; no behavior change is intended.Checklist
This is an AI-assisted change.