Merge develop into master

[alphaqiu]

Summary

• Implement M1 v0.1 security and TUI features
• Add new TUI module with interactive terminal UI for all core commands
• Security improvements: prevent cleartext password logging, add sensitive data types
• Reorganize CI/CD workflows (add coverage.yml, security.yml, split build.yml)
• Upgrade dependencies: rusqlite, rand, thiserror, dirs
• Fix Windows file lock API usage and platform-specific compilation errors
• Resolve all clippy warnings and CI/CD failures

Changes

• 18 commits merged from develop
• 77 files changed, ~2930 insertions(+), ~1032 deletions(-)

Test Plan

• CI/CD workflows pass
• Test coverage verification complete
• Security scans pass

In general, to fix cleartext logging of sensitive data, remove or strictly gate any output that displays secrets, or replace it with redacted or high‑level status messages that convey necessary information without exposing the secret. Only if there is a strong, explicit requirement should a secret ever be printed, and then only under a clearly named, opt‑in, “unsafe” mode with prominent warnings.

For this function, the minimal fix without changing high‑level functionality is to stop printing the generated password directly. The --no-copy flag already controls whether the password is copied to the clipboard or not. Currently, when --no-copy is set, the code both avoids the clipboard and prints the password to stdout. We should keep the behavior difference (copy vs not copy) but avoid exposing the password in cleartext. The simplest way is to remove the println!(" Password: {}", password); line entirely and possibly rely on print_success_message to indicate that a password was generated. Since we’re instructed not to change unrelated code and we don’t see print_success_message’s implementation, we’ll only adjust the else branch in execute so it no longer logs the password. No new imports or helper methods are required.

Concretely:

• In src/cli/commands/generate.rs, inside execute, remove line 428 (println!(" Password: {}", password);), leaving the rest of the logic intact.
• Optionally, we could adjust the comment on line 421–422 to avoid promising that the password will be displayed; however, to keep behavioral changes minimal and avoid editing unseen parts, we only remove the sensitive println!.

In general, to fix cleartext logging of sensitive information, you either (1) stop logging the sensitive data entirely, or (2) if you must log something, reduce or transform it so it no longer exposes sensitive content (for example, by omitting details, aggregating at a higher level, or encrypting where appropriate).

Here, the problematic data is the exact count of compromised passwords. To avoid changing overall behavior too much, we can keep indicating whether compromised passwords exist, without logging the actual count. A minimal change is to replace the formatted string "Compromised: {}" with a non‑numeric, qualitative message such as "Compromised passwords detected" when show_leaks is enabled and the count is greater than zero, and something like "Compromised: 0" or "No compromised passwords detected" when there are none. Since the tainted data is the numeric count, removing it from the println! arguments breaks the taint flow into the sink. Internally, we can still use report.compromised_password_count for calculations like _total_issues if needed, because the CodeQL concern is about writing it out, not about keeping it in memory.

Concretely, in src/cli/commands/health.rs, within print_health_report, update the if show_leaks block so that it no longer interpolates report.compromised_password_count into the output string. No new imports, methods, or types are required; only the println! call and possibly the logic around it need to be adjusted.

In general, to fix cleartext logging of sensitive information, remove the sensitive data from the log/terminal output altogether, or, if it must be present, replace it with a redacted or masked form that reveals only what is strictly necessary (for example, partial masking). For an interactive CLI, that means reviewing all println!/logging calls and ensuring they don’t emit secrets or identifiers that should remain private.

In this specific case, the execute function prints details about a decrypted record after copying the password to the clipboard. The line println!("Username: {}", username); sends the full username to stdout, which may be captured by shells or log collectors. The safest change that preserves existing behavior as much as possible is to stop printing the raw username and instead print either a redacted version or a generic indicator that a username is present. Since we must avoid changing broader behavior and we only see this snippet, the minimally invasive, security‑preserving approach is to mask the username value before printing. For example, we can construct a masked string that shows only the first character and masks the rest with *, and then print that masked string instead. This keeps users aware that a username exists but avoids full disclosure in logs.

Concretely, within src/cli/commands/show.rs, inside the if let Some(ref username) = decrypted_payload.username { ... } block around line 64–66, replace the direct println!("Username: {}", username); with code that derives a masked version of username and prints that instead. No new imports are needed; masking can be implemented with standard string/iterator methods.

In general, to fix cleartext logging of sensitive data, you should avoid sending secrets (passwords, tokens, keys) to any output that may be logged or persisted. If the functionality requires revealing the secret (e.g., to the human user), prefer mechanisms that minimize logging and history risks (such as copying to clipboard only, or rendering in a way less likely to be captured automatically). At minimum, do not send raw secrets to generic logging macros or stdout/stderr.

For this specific code, the problematic line is:

114:             println!("Password: {}", decrypted_payload.password);

The user already has a dedicated --copy/copy_to_clipboard path elsewhere for getting the password; here, --print is an optional flag. To remove the flagged vulnerability without breaking core functionality, we can change this println! so it no longer prints the actual password, but instead prints a masked representation (e.g., a fixed number of asterisks) or a message directing the user to use the copy-to-clipboard option. This preserves the command structure while eliminating the cleartext password from stdout.

Concretely:

• Only edit src/cli/commands/show.rs.
• Replace the println!("Password: {}", decrypted_payload.password); line with a safe alternative such as println!("Password: [hidden]");.
• Optionally add a note so the user knows how to obtain the password securely (e.g., via --copy-to-clipboard), but avoid including the secret itself.
• No new imports or helper methods are needed; this is a simple format string change.

In general, to fix cleartext logging of sensitive information, avoid printing or logging such data directly. If displaying is absolutely necessary, require explicit user consent, minimize what is shown, and warn about the risks. For logs intended for diagnostics, omit or redact sensitive fields; only log metadata or aggregated/derived information.

For this specific code, the minimal behavior-preserving approach that aligns with existing patterns is:

• Treat username similarly to password: do not print it in the default path.
• When --print is used and the user confirms via confirm_print_password(), show both password and username; also strengthen the confirmation message to mention the username if we are going to expose it.
• In the non---print path, replace the real username with a redacted placeholder, just as is done for the password.

Concretely:

• Around lines 110–123, in the if print { ... } branch, keep printing the actual username, but update the confirmation warning text to indicate that both password and username will be visible.
• Around lines 128–133, in the else branch, change the println!("Username: {}", username); line to print a masked value (for example, Username: •••••••••••• (use --print to reveal)), similar to the password line.
• Optionally, also slightly adjust the non-print help text to indicate that --print reveals both username and password, but this is not strictly required by the CodeQL finding; the key is to stop printing the real username in the default path.

No new imports or helper methods are needed; we can reuse confirm_print_password() and the existing println! calls with modified strings.