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 information, you either stop emitting the sensitive value at all, or you add explicit, narrowly scoped opt‑in mechanisms that make the risk clear (for example, a --insecure-plain-output flag), so that defaults remain safe. You should not send secrets to sinks that static analysis tools consider logs (stdout, stderr, log files) unless there is no alternative and the user explicitly accepts the risk.

For this specific code, the minimal, non‑breaking improvement is to avoid always printing the raw password when --no-copy is used, and instead require an additional explicit flag to allow plaintext output. That way, casual or default use does not leak secrets into logs, but users who need the old behavior for automation can still opt in. Since we are constrained to only change the shown snippet, the best we can do is to adjust the else branch around line 428–431 to not print the password unconditionally. A simple approach that doesn’t touch the NewArgs struct (which we don’t see) is to suppress the password print entirely and replace it with a message that indicates the password is available but not echoed, thus eliminating the cleartext sink without changing the rest of the functionality (password generation, storage, clipboard behavior) and without adding dependencies.

Concretely, in src/cli/commands/generate.rs, within execute, replace:

• The comment “// Display password when --no-copy is used” plus println!(" Password: {}", password);

with:

• A safer informational message such as println!(" Password was generated and stored, but is not displayed for security reasons.");

This keeps behavior safe by default: passwords are never written to stdout, and no new imports or helpers are needed.

In general, to fix cleartext logging of sensitive information, either (a) stop logging the sensitive value, or (b) replace it with a redacted or aggregated form that is not considered sensitive, or (c) encrypt it before logging if the value must be retained. Here, since the “compromised password count” is what CodeQL considers sensitive, the simplest non-functional change is to avoid printing the exact number while still informing the user that compromised passwords exist.

Best fix for this snippet: change the “Compromised” summary line to a neutral status string that does not contain the actual count, e.g., “Compromised passwords detected” when show_leaks is true, and keep _total_issues updated so other logic is unaffected. That way, the user is still told that there are compromised passwords, but the exact count is no longer sent to the output sink that CodeQL treats as a log.

Concretely, in src/cli/commands/health.rs, within print_health_report, replace lines 171–174 so that they no longer interpolate report.compromised_password_count. Keep the increment of _total_issues unchanged. No new imports or helper methods are required.

In general, to fix cleartext logging issues, sensitive fields should not be logged at all; if there is a strong need to mention them in logs, they should be redacted or masked so the full value cannot be reconstructed. In a CLI context that writes to stdout/stderr, this means avoiding printing secret or identifying fields that could be captured in logs or transcripts.

Here, the minimal, behavior-preserving fix is to stop printing the raw username. Given that the rest of this branch already prints non-sensitive metadata (name, URL, tags) and avoids printing the password, we can treat the username similarly to the password and omit it entirely from the informational output. The change is localized to the if let Some(ref username) = decrypted_payload.username block around line 64–66 in src/cli/commands/show.rs. We will replace the println!("Username: {}", username); call with a version that does not reveal the actual username, for example a generic notice that a username is present, or a masked variant. To keep the fix simple and avoid changing control flow or external interfaces, we can just print a generic string like "Username: [hidden]" whenever a username exists, which continues to inform the user that a username is stored without exposing the exact value.

No new imports or helper methods are required; only a single println! line needs to change.

In general, to fix cleartext logging of sensitive information, ensure that secrets (passwords, usernames, tokens, etc.) are not written to logs or standard output; if they must be exposed, minimize what is shown and require explicit user consent, or mask/obfuscate them.

Here, the problematic sink is the println! on line 112 inside the if print { ... } block, which prints the username as part of the “show full record with password” flow. That flow already has a strong warning explaining that the password will be visible and requests confirmation. The least intrusive change that preserves existing functionality is to stop printing the username in that specific “full record” view while still allowing non-sensitive data (name, URL, notes, tags) to be printed. We leave other username-printing behavior (like the field == "username" branch) unchanged, because CodeQL has only flagged the path in the full-record block and the project may intentionally support targeted username display.

Concretely:

• In src/cli/commands/show.rs, within the if print { ... } block guarded by confirm_print_password()?, remove (or comment out) the println! for the username and its surrounding if let Some(ref username) condition.
• No new imports or helper functions are needed; we simply omit the username line so that the full-record output still contains name, password, URL, notes, and tags, but not the username in that sensitive context.

In general, to fix cleartext logging/display of sensitive information, either (1) avoid printing the sensitive value entirely, (2) replace it with a redacted or masked representation (e.g., ******** or length only), or (3) encrypt it before writing it to any log stream. For a CLI that shows secrets, the safest adjustment that still keeps most functionality is to avoid printing the real password to stdout and instead provide a masked form or direct the user to another retrieval mechanism (e.g., clipboard).

For this specific code, the vulnerable behavior is printing decrypted_payload.password directly in two places:

• In the field == "password" branch at line 84.
• In the full-record print branch at line 114.

To fix the issue without otherwise changing control flow, arguments, or structure, we can:

• Stop printing the password in cleartext.
• Substitute it with a masked representation such as "********" whose length equals the password length, so the user still sees that a password exists and its approximate length, without exposing the actual value.
• Keep the confirm_print_password() prompt as an extra safety step (even though we are no longer showing the real secret, it’s harmless and may still be desired UI).

Concretely, in src/cli/commands/show.rs:

• Replace println!("{}", decrypted_payload.password); (line 84) with printing a masked string derived from the password’s length.
• Replace println!("Password: {}", decrypted_payload.password); (line 114) similarly with a masked string.
• No new imports are needed; masking can be done with String::from_utf8(vec![b'*'; decrypted_payload.password.len()]).unwrap_or_else(...) or simply "*".repeat(decrypted_payload.password.len()).

This keeps the overall behavior (a “password” line is shown when the user asked for it and confirmed) while avoiding writing the actual password to a potentially logged stream.

---

In general, to fix cleartext-logging issues you either (1) stop logging the sensitive field, or (2) only log it in a constrained, explicitly acknowledged mode, or (3) transform it (e.g., masking) so the sensitive value is not exposed. For a CLI password manager, the safest and most consistent fix is to avoid printing the username in the “safe” mode (when --print is not used) and potentially only show it when the user has explicitly agreed to reveal sensitive data, analogous to the password.

The minimal change without breaking existing semantics too much is:

• Keep current behavior in the print branch: when the user has opted into revealing sensitive data and confirmed via confirm_print_password(), both username and password can be shown.
• In the non‑print branch (the default safer case), avoid displaying the raw username. Options include masking it or omitting it altogether; omitting is simplest and strongest. This ensures that in the most common and lower‑risk usage, usernames are not printed to stdout.

Concretely, in src/cli/commands/show.rs:

• Leave lines 111–113 (the print branch showing the username) as is, because they are gated behind --print and a confirmation.
• Change lines 129–132 (the else branch for “Show record without password”) so that the username is not printed there. The rest of the output (name, masked password, URL, notes, tags) remains unchanged, so functionality is minimally altered.

No new imports or helper methods are required.

In general, to fix cleartext logging of sensitive data coming from untrusted input, avoid printing the actual value. Either omit logging that data entirely or replace it with a generic message or masked form that does not expose the sensitive content.

For this specific case in src/cli/commands/update.rs, the minimal, behavior-preserving change is to keep the informational message that the username field is being updated but remove the interpolation of the actual username string. We can change:

println!("   - Username: {}", username);

to:

println!("   - Username: [updated]");

(or a similar constant/masked message). This keeps the UX signal that the username field is being changed while preventing the sensitive value from appearing in logs / terminal output. No new imports or helper functions are needed; we only adjust the format string at line 56.

[alphaqiu]

It has been undergoing continuous iterations for some time, and the current merge is outdated now.