Harden uinput preflight and setup foundations#12
Conversation
The uinput setup path now treats user-group changes like the other best-effort side effects, so setup can keep reporting recovery steps even if groupadd, usermod, or sudo/root user detection fails after earlier mutations. The completion banner also only tells users to relog and start using whispers when a fresh login is the last remaining injection prerequisite. Constraint: Published PR review comments should be addressed as follow-up commits, not history rewrites Rejected: Keep bubbling add_user_to_group errors | aborts after partial system mutations and hides recovery guidance Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep final setup status aligned with the post-setup readiness report; do not report completion when non-relogin prerequisites still fail Tested: cargo test --quiet Not-tested: interactive sudo-driven whispers setup on a live system
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b51db87f3b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let readiness = crate::inject::InjectionReadinessReport::collect(); | ||
| if readiness.is_ready() || !readiness.has_uinput_issue() { | ||
| return Ok(InjectionSetupOutcome::default()); |
There was a problem hiding this comment.
Base uinput setup on non-root user permissions
Avoid short-circuiting setup from root-only readiness: this check uses the effective user, so when whispers setup is launched via sudo, InjectionReadinessReport::collect() can report /dev/uinput as ready for root and return early without creating the uinput rule/group path needed by the actual desktop user. In that scenario setup appears complete, but running whispers as the normal user still fails injection preflight with permission errors.
Useful? React with 👍 / 👎.
Move install, CLI, and troubleshooting detail out of the README so the front page stays focused while the deeper docs remain aligned with the current command surface and distribution paths.
Constraint: README should stay concise without hiding operational guidance
Constraint: Documentation claims must match the current CLI, release workflow, and package metadata
Rejected: Keep all reference material in README | harder to scan and easier to let drift
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Re-check README install claims against release assets, AUR packages, and CLI help before future doc refreshes
Tested: cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test; markdown local link check; verified GitHub release v0.2.2 and AUR package pages for whispers{-bin,-git,-cuda-bin,-cuda-git}
Not-tested: GitHub web markdown rendering
Record whether the udev reload step actually succeeded and only give the relogin-only setup message when that prerequisite is met. Also wait for udev to settle before the immediate post-setup readiness probe so fresh setups are judged against the updated device node state. Constraint: Setup should not tell users that relogging alone will fix paste injection after a failed udev reload Constraint: The post-setup readiness probe runs immediately after the helper returns Rejected: Trust the follow-up readiness probe alone | it cannot distinguish a stale device node from a reload failure Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep setup messaging tied to the actual side effects that completed, not just the current readiness snapshot Tested: cargo test setup::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: End-to-end sudo/udev behavior on a live system
Remove duplicated relogin-guidance branching from the setup reporting path so the immediate setup output and the final completion message both derive from the same recorded outcome. This keeps the recent udev-readiness fix easier to follow without changing the guarded behavior. Constraint: Cleanup stays scoped to the recent setup readiness fix files Constraint: Group-change guidance must still reflect whether the udev reload succeeded Rejected: Leave the branching duplicated in each reporting callsite | easier for the messages to drift again Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep setup messaging decisions attached to InjectionSetupOutcome instead of recomputing them ad hoc in each UI path Tested: cargo test setup::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: End-to-end sudo/udev behavior on a live system
Treat a setup rerun the same as a same-run group change when the user is already configured for the uinput group and the current run successfully reloads udev. This keeps the final setup summary aligned with the real remaining recovery step without reviving the earlier failed-reload bug. Constraint: Relogin-only guidance must stay blocked after a failed group membership change or failed udev reload Constraint: The fix should stay scoped to the setup outcome/report path and regression tests Rejected: Infer group readiness from changed_groups alone | misses reruns and manual prior membership Confidence: high Scope-risk: narrow Reversibility: clean Directive: Track whether setup left the user correctly configured for the uinput group instead of inferring that only from whether this run changed group membership Tested: cargo test setup::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: Live sudo/udev behavior
Require read-write access when probing /dev/uinput so preflight matches the real virtual-device builder, and resolve existing uinput groups through NSS instead of only /etc/group. This keeps setup guidance accurate on systems with stricter device permissions or non-local group sources. Constraint: Injection preflight must reflect the same access mode the virtual keyboard actually needs Constraint: Group discovery must honor NSS-backed sources used by the rest of setup Rejected: Keep a write-only probe and /etc/group scan | both can report false readiness in real environments Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep setup and preflight environment checks aligned with the runtime code paths and NSS-backed identity lookups Tested: cargo test inject::tests:: -- --nocapture; cargo test setup::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: Live sudo/udev behavior and NSS-backed groups outside the local test environment
Suppress stale manual fix steps when setup has already reached the relogin-only state, and make username lookup retry when NSS reports the passwd buffer hint was too small. This keeps the automatic uinput setup path consistent across reruns and larger NSS-backed passwd records. Constraint: Relogin-only guidance must not repeat manual setup steps that already succeeded Constraint: Username lookup must retry when NSS says the passwd buffer hint was too small Rejected: Keep printing readiness fix lines unconditionally | contradicts the final setup summary when only relogin remains Rejected: Trust a single getpwuid_r buffer attempt | NSS backends can still return ERANGE after the size hint Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep setup reporting aligned with the actual remaining recovery step, and treat NSS buffer-size hints as advisory Tested: cargo test setup::tests:: -- --nocapture; cargo test inject::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: Live sudo/udev behavior and large NSS passwd records outside the test environment
Only activate the new uinput rule once the user is actually ready for it, and keep relogin-only guidance gated on the rule being in place. This prevents partial setup failures from regressing access or hiding the remaining manual work. Constraint: Reloading udev must not switch /dev/uinput to the new group before membership is ready Constraint: Relogin-only guidance must stay blocked when the udev rule still is not in place Rejected: Always reload udev after touching setup files | can activate the new group rule before membership exists Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep setup outcome state explicit enough to distinguish relogin-only cases from incomplete privileged setup Tested: cargo test setup::tests:: -- --nocapture; cargo test inject::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: Live sudo/udev behavior on a host that still relies on legacy input-group access
Prevent `whispers setup` from short-circuiting on root-only `/dev/uinput` readiness, which can otherwise report success without configuring the actual desktop user. Constraint: Automatic uinput setup should be evaluated for the real desktop user, not sudo-root permissions Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep setup privilege checks explicit so root-only readiness can never masquerade as user readiness Tested: cargo test setup::tests:: -- --nocapture Not-tested: Live sudo invocation
Keep the bundled and packaged README links valid by shipping the docs pages it references in release bundles and Cargo package contents. Constraint: Packaged README links should not point to files that are omitted from shipped artifacts Confidence: high Scope-risk: narrow Reversibility: clean Directive: If README starts linking to new local docs, add those files to package and release artifact manifests in the same change Tested: cargo package --list --allow-dirty; scripts/build-release-bundle.sh with temp dist dir (verified docs in tarball) Not-tested: GitHub release workflow end-to-end
Reject `whispers setup` at the start of the setup flow when it is launched as root so it cannot mutate config or starter files before reporting the privilege error. Constraint: Root-only setup runs must fail before any local state is written Rejected: Leave the root guard inside the later injection setup helper | config and starter files can already be mutated before that point Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep the root guard at the top of `run_setup()` so later helpers cannot become the first failing point again Tested: cargo test setup::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: Live sudo invocation
Make the non-zero clipboard test consume stdin before exiting so CI reliably exercises the intended non-zero exit path instead of racing into a broken-pipe write. Constraint: The test should still cover the non-zero exit path, not the broken-pipe write path Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep subprocess tests deterministic by making the child process consume the expected I/O before exiting Tested: cargo test inject::tests:: -- --nocapture; cargo fmt --all -- --check; cargo check --all-targets; cargo clippy --all-targets -- -D warnings; cargo test Not-tested: GitHub Actions rerun still pending
Summary
/dev/uinputpermission and setup handlingVerification
cargo fmt --all -- --checkcargo check --all-targetscargo clippy --all-targets -- -D warningscargo testThis is the root of a small stacked series.