audit export publishes request_hash, an unsalted hash over unredacted params, with no statement of its sensitivity

[vladimirrott]

Scope 1 shipped in #318 on 2026-09-01. Read this as an HMAC issue.
Verified at 30b9e315 on 2026-09-17: docs/cli.md:167 and
docs/the-audit-chain.md:404 both state the confidentiality class, and
tests/release/audit-export-confidentiality.test.sh fails if the two calls
below ever swap order. What is left is Scope 2, which needs an HMAC over the
request and a chain_version bump, so the hard half is the whole issue now.

The two line numbers have also moved twice. At 30b9e315 they are
dispatcher.rs:2224 (compute_request_hash) and dispatcher.rs:2264
(redact_params), not the 2001 and 2041 the paragraph below quotes.

request_hash is a column of every signed chain row, and sysknife audit export (#260) now serialises it. The hash commits to the unredacted request:

crates/sysknife-daemon/src/dispatcher.rs:2001   let request_hash = compute_request_hash(action_name, params);
crates/sysknife-daemon/src/dispatcher.rs:2041   let redacted_params = redact_params(action_name, params);

Redaction runs 40 lines after the hash, and compute_request_hash is one unsalted round:

hasher.update(action_name.as_bytes());
hasher.update(b"\x00");
hasher.update(canonical.as_bytes());

Why it matters

For ConfigureWifi the credential params are password and ssid. The SSID is broadcast, so the only unknown in the preimage is the passphrase, and a single unsalted SHA-256 is the cheapest thing a GPU cracks. The daemon keeps the database 0600 inside a 0700 directory precisely so this content does not travel; an export moves it across that boundary by design, into a SIEM, a ticket, or an auditor's laptop.

High-entropy credentials such as ProAttach tokens are unaffected. The problem is the low-entropy human-chosen ones.

The column cannot simply be dropped: request_hash is part of ChainContent::canonical_bytes (crates/sysknife-daemon/src/audit_chain.rs:508), so an offline verifier needs it to rebuild the signed bytes.

Scope

Two parts, and the first is the one that matters today:

1. Say plainly in docs/cli.md and docs/the-audit-chain.md that an export inherits the database's confidentiality class and is not a redacted artifact. Done in feat(cli): export audit chain rows as JSON #318 on 2026-09-01, guarded by tests/release/audit-export-confidentiality.test.sh.
2. Consider replacing the bare hash with an HMAC keyed by the audit key. That keeps the binding an offline verifier needs while removing the offline-crackable commitment, at the cost of a chain_version bump and a verifier that has the key.

Tests first

Part 1's guard is on main already. For part 2, a round-trip test that an HMAC-bound row still verifies, plus a migration test across chain_version, and a negative case: a row written under the old chain_version must still verify after the change, or the bump has silently invalidated every existing trail.

Difficulty

hard. The documentation half that made this medium has shipped. What remains touches the signed encoding, so it needs the HMAC, a chain_version bump and a verifier that holds the key.

Getting started

CONTRIBUTING.md has the build and test commands, and docs/developer-guide.md covers the setup steps and how to reproduce each required check locally. No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

@danial-razi the export half of this is on main now, in #318, along with a statement in docs/cli.md and docs/the-audit-chain.md about what an export inherits and a check that fails if compute_request_hash ever stops running before redact_params.

The other half is still open, and you have more context on this file than anyone. request_hash is an unsalted SHA-256 over the unredacted parameters, so for an action like ConfigureWifi, where the SSID is broadcast anyway, the passphrase is the only unknown left in the preimage. A per-install key or salt is the remaining work.

No obligation, and thanks again for the export.

[vladimirrott]

Audited at d881d49. The first half of the scope shipped in #318 on 2026-09-01.
The second half is untouched. Anybody picking this up should read it as an
HMAC issue now.

Scope 1 is done

The body says the docs "enumerate what export omits and say nothing about what it
carries". They now say it:

$ grep -n 'not a redacted artifact\|request_hash' docs/cli.md docs/the-audit-chain.md
docs/cli.md:167:An export is not a redacted artifact. It inherits the confidentiality class of
docs/cli.md:171:Every row carries `request_hash`, a single unsalted SHA-256 over the action name
docs/cli.md:172:and the **unredacted** parameters. `compute_request_hash` runs before
docs/cli.md:179:The column cannot be dropped, because `request_hash` is part of the signed bytes
docs/the-audit-chain.md:24:| `request_hash` | Commitment to the exact request that was previewed |
docs/the-audit-chain.md:405:redacted artifact. `request_hash` commits to the unredacted parameters as one

There is a guard holding it in place, so it cannot silently regress:

$ ls tests/release/audit-export-confidentiality.test.sh
tests/release/audit-export-confidentiality.test.sh

Scope 2 is open, and it is the whole issue now

$ grep -rn 'Hmac\|hmac' crates/ --include=*.rs

No output. Nothing in the tree is keyed. The bare unsalted commitment is still what
ships in every exported row.

Three corrections to the body

Both line numbers moved. The 40-line gap the body relies on is intact:

$ grep -n 'compute_request_hash\|redact_params' crates/sysknife-daemon/src/dispatcher.rs | head -4
50:// param keys. `redact_params` replaces each credential value with the literal
66:fn redact_params(action_name: &str, params: &Value) -> Value {
967:pub fn compute_request_hash(action_name: &str, params: &Value) -> String {
2179:    let request_hash = compute_request_hash(action_name, params);
$ grep -n 'redact_params(action_name, params)' crates/sysknife-daemon/src/dispatcher.rs
2219:    let redacted_params = redact_params(action_name, params);

2001 is 2179 and 2041 is 2219. The difference is still 40.

ConfigureWifi redacts one key, not two. The body treats ssid as a
credential alongside password. Only password is in the set:

$ sed -n '55,62p' crates/sysknife-daemon/src/dispatcher.rs
/// Per-action credential param keys. Add new actions here when they take secrets.
fn credential_keys_for(action_name: &str) -> &'static [&'static str] {
    match action_name {
        "ProAttach" => &["token"],
        "ConfigureWifi" => &["password"],
        _ => &[],
    }
}

This makes the threat argument slightly stronger rather than weaker. ssid is a
plain param, so it goes into the hash in the clear alongside the password, and an
attacker guessing the password has the network name for free.

The landed pull request is #318, not #260. #260 closed unmerged.

Difficulty

The body offers medium for the documentation half and hard for the HMAC. Only
the hard half is left, so I would read the label as hard from here. I have not
changed it, because whoever takes this may want to split the chain_version
migration off as its own issue, and that decision changes the answer.

[vladimirrott]

@sonalisrisivani reserved for you as a follow-up to your recent work; the why is on your PR thread. No pressure and no deadline. Reply here and it is formally yours.

[vladimirrott]

@sonalisrisivani same correction as on #234, and the same apology.

I reserved #268 for you on 7 September when it had already been pointed at somebody else, and neither of you heard about the other from me. I found it by fixing the tool that exists to stop exactly this: it counted the issues free to offer without ever naming them, so every round of offers picked by hand and collided.

Releasing this one while you finish #379 and #380. It comes back the moment you want it.

[vladimirrott]

@danial-razi checking in, with nothing attached to it. I pointed you at this on 1 September and have not heard back.

If you are still on it, it stays yours and I will stop asking. If you would rather have something smaller to start with, say so and I will find one. And if this is not the week for it, tell me and I will put it back in the pool with no hard feelings.

Silence is an answer too, and I will read it as the last one after another week.

[vladimirrott]

@danial-razi I pointed you at this on 9 September and have not heard back, so it goes back in the pool for whoever has time. Nothing went wrong on your side.

If you still want it, it is yours again for the asking. If something smaller would be a better first one, say so and I will find you one.

[vladimirrott]

@atanishka308 following on from what I said above: this one may suit you better, if you want it.

Your #385 sanitized the distro version string before it reached prompt interpolation. #268 is the same instinct pointed at the audit export: it publishes request_hash, an unsalted hash over unredacted request data, so anybody holding a guess can confirm it by hashing the guess. A hash used as a pseudonym is not redaction.

Medium. The work is choosing what makes the field useful without making it a lookup table, and proving the old value can no longer be confirmed by guessing.

Yours if you want it. Tell me if you would rather have something else.

[atanishka308]

Hi @vladimirrott, thank you for considering me for this issue. I’m still a beginner and currently at the learning stage with Rust and open-source contributions. After looking into #268, I feel the HMAC and chain-version changes are quite tough for me compared to the previous issue I worked on.

I’d like to continue contributing to Sysknife, so could you please assign me a smaller/easier issue that would be more suitable for my current level? I’d really appreciate the chance to learn and gradually take on more complex issues.

Thank you for understanding!

[vladimirrott]

@atanishka308 that was the right call, and saying so saved us both a fortnight. #268 needs an HMAC and a chain-version migration underneath it, which is a different order of work from your #385, and nothing about your reading of it was wrong.

Releasing it back into the pool. It is yours again for the asking if you come back to it later, and nothing about today closes that door.

I have answered your request on #440 and it is yours.