Harden execution safety, secrets, jobs, and persistence

[magetsu002]

Overview

This PR improves Chronosphere's reliability and safety across execution, job handling, persistence, and validation.

The goal is to make runtime behavior more predictable, prevent unsafe states, and improve recovery from failures without expanding the command library or changing the TUI.

What changed

Execution safety

• explicit validation for targets, credentials, access points, pivots, and engagements;
• prevents unsafe fallback behavior when execution context is ambiguous;
• validates engagement paths and keeps them inside the configured root;
• improves execution context stored with jobs.

Secret handling

• detects and redacts sensitive values from commands, history, logs, and MCP responses;
• improves protection of sensitive files and stored state;
• prevents credentials from leaking through SSH/SCP execution paths.

Job reliability

• persists subprocess runtime identity;
• supports startup reconciliation of interrupted jobs;
• enables safe cancellation after restart;
• improves tracking of success, failure, timeout, and cancellation states.

Log handling

• replaces full-file log reads with bounded streaming;
• improves tail and grep behavior on large outputs;
• adds limits and safer handling for large command results.

Persistence and recovery

• improves atomic state updates and failure handling;
• makes CVE-related updates transactional;
• adds doctor checks and repair support for stale jobs and orphaned runtime artifacts.

Validation

Added and updated coverage for:

• subprocess recovery;
• cancellation flows;
• large log handling;
• security-sensitive behavior;
• persistence failures.

CI validates:

• cargo fmt --check
• locked Clippy checks
• full locked test suite
• locked release build

Scope

No command-library expansion, unrelated features, or major UI redesign included.

[FGH-2]

Thank you for the contributions! I will comment on a specific thing in this PR for now. It might be not the only comment I do, I will comment on the PR if I find any other thing that might need to be discussed.

Currently this PR has many features and I think a specific change should be on its own PR just because I feel it wouldn't work with the tool as it is right now.

When I've thought about how should we store passwords, hashes, or any sensitive information related to an engagement, I was thinking of HTB as the main target or any other CTF platforms, where you usually don't really care that much about sensitive information and such.

I've went with the simple route because it was good enough for me. But for sure when it comes to real engagements that's not the case. This information must be indeed redacted in some way and be stored secretly.

Now when you're doing an engagement, imo it's annoying to have commands and passwords redacted. Sometimes you need to confirm if you're using the correct information. Having information redacted in the logs can be annoying if you ever want to continue an engagement from were you left.

Also MCPs needs this information exposed if you're ever competing for a blood. The current model requires some modifications but it needs to be on a separate PR in order to fully grasp the whole thing without other features getting in the way

The modification I was thinking of is that if you really need this tool to have compliance with privacy and whatever fancy GRC terms out there then you need to encrypt the information in a way that the tool has the encryption key loaded, you do your engagement, things are stored safely and you can exit the tool without worrying about the information being exposed

Another thing that might be helpful for pentesters is that if they can supply a flag when using the CLI where it prints back the command but redact the sensitive information. This could be useful in someway for writing reports. I'm not sure how well can this go because usually pentesters must also redact sensitive infromation in the command output as well.

That's all I have for now related to secret handling.

Thank you!

[magetsu002]

Thanks for the detailed feedback!

I agree that secret handling deserves its own PR. The current changes were focused on preventing accidental leakage, but I agree they also change the workflow assumptions around how operators interact with credentials during engagements.

I originally approached it from a security-first perspective, but your point about HTB/CTF workflows and needing visibility during engagements makes sense.

I'll separate this into its own discussion/PR where we can design it properly instead of forcing it into this reliability pass.

Some ideas I think are worth exploring:

• encrypted credential storage instead of only redaction;
• explicit operator-controlled secret visibility;
• a CLI mode for generating sanitized commands for reports;
• MCP-specific handling where agents can access required context without exposing secrets unnecessarily.

I'll keep this PR focused on the reliability and recovery improvements.