id(server_config): a blank or whitespace-padded key passes parse — a blank user key fails only mid-provisioning after earlier users are already created, and a padded key silently diverges from the account name it creates

id(server_config): a blank or whitespace-padded key passes parse — a blank user key only fails mid-provisioning, after earlier users are already created

Summary

ServerConfig::parse (pkgs/id/src/server_config/parse.rs) blank-checks every
human-facing string it accepts except the key itself:

group name: trim().is_empty() → ConfigError::Empty { field: "name" } (parse.rs, group pass)
alias: trimmed, blank → ConfigError::Empty { field: "alias" } (record_alias)
role: trimmed and lower-cased before matching (parse_role)

But claim() (the one place every user/group key passes through) records the
key verbatim — no trim, no empty check:

fn claim(names: &mut BTreeMap<String, Object>, key: &str, object: Object) -> Result<(), ConfigError> {
    if names.contains_key(key) {
        return Err(ConfigError::DuplicateKey(key.to_owned()));
    }
    names.insert(key.to_owned(), object);
    Ok(())
}

So key = "", key = " ", and key = " ann " are all accepted for users
and for groups, and every reference (creator, members[].user,
[create].users/groups) resolves against the verbatim string.

Why it matters

The user key is not just a local label: provisioning passes it as the
account's name — Provisioned::apply calls
directory.sign_up_keyed(&id, &user.key) (provision.rs), and
Directory::insert_account runs that name through clean_name
(directory.rs), which trims it and refuses an empty one
("name must not be empty"). Consequences, all verified this run (see below):

A blank user key passes parse and fails only at provisioning, as a
ProvisionError::User wrapping the directory's "name must not be empty" —
not as a ConfigError naming the key. apply creates users in file
order and returns on the first failure, so every user listed before the
blank-key user has already been created when it fails. The module doc's
promise — "ServerConfig::parse checks the whole file … so a bad file
fails at startup" — is exactly what the blank check on names/aliases
delivers and the key check misses.
A whitespace-padded key silently diverges from the account it creates.
Keys "ann" and " ann " are distinct keys to claim (no
DuplicateKey), both provision successfully, and both accounts end up
named ann (the directory trims; the config does not). Afterwards
config.user_id(" ann ") resolves, while the directory knows the account
only under the trimmed name.

Evidence (verified this run, main `528886e`)

Laptop probe in the real crate (worktree of origin/main at
~/git/fleet/probe-2026-10-28-laneA-configkey, integration test
pkgs/id/tests/probe_configkey.rs calling the public
ServerConfig::parse / Provisioned::apply; parse.rs sha256 on the
laptop worktree identical to the sandbox clone,
14673ade04923b574ea2adaedeebda03cf967e0d403bed28e4caa6cec450210d):

key = "" user → parse Ok; key = " " user → parse Ok;
blank group key → parse Ok
controls: blank group name → Err(Empty { field: "name" });
blank alias → Err(Empty { field: "alias" })
config [ann (good), "" (blank)] → apply fails at the blank user with
the directory's empty-name refusal, and the good user's account already
exists in the directory afterwards
config with keys "ann" and " ann " (different ids) → parse Ok, apply
Ok, and the directory holds two accounts both named ann

(Full probe output is attached in the filing run's bookkeeping:
hidden_files/probe-2026-10-28-laneA-configkey/ in the fleet goal workspace.)

Acceptance criteria

ServerConfig::parse refuses a user or group key that is empty or
whitespace-only, with a ConfigError that names the offending entry the
way Empty names a blank name/alias (a dedicated variant is fine).
The rule for surrounding whitespace is pinned one way or the other by
tests: either keys are trimmed before claiming (so " ann " is ann,
and a repeat is DuplicateKey), or padded keys are refused at parse.
Silent divergence between the config key and the provisioned account
name must be impossible.
References (creator, members, [create]) follow the same rule as the
declarations they name.
Existing config parse/provision tests keep passing, including the
blank name/alias refusals and the duplicate-key refusals.
New tests cover: blank user key, blank group key, whitespace-only key,
and the pinned padded-key behaviour.

CODE-754

🤖 Agent note · state: filed

Agent: new-issue-creator job (new-issue-creator-code-a)
Session / ID: new-issue-creator-code-a run 2026-10-28 15:44 CDT (job_id new-issue-creator-code-a)
Found via: filed this run
Task: Filed this issue: server_config parse never blank-checks user/group keys — a blank user key fails only mid-provisioning (after earlier users are created) and a whitespace-padded key silently diverges from the trimmed account name it creates. Verified this run with a real-crate probe on the laptop at origin/main 528886e.
Expectation: effort/xs–s; done when parse refuses blank/whitespace-only keys naming the entry, the padded-key rule is pinned by tests, and existing parse/provision tests pass.
Links: queue packet enqueued this run (repo-health-code-pilot)

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), lane A shift
Session / ID: task 5050
Found via: queue claim
Task: Implement issue id(server_config): a blank or whitespace-padded key passes parse — a blank user key fails only mid-provisioning after earlier users are already created, and a padded key silently diverges from the account name it creates #1824: reject blank and whitespace-padded user/group declaration keys in ServerConfig::parse (parse-time rejection, no trimming), with focused tests.
Expectation: effort xs; done = branch queue/5050-1824-blank-key-rejection pushed, PR opened, cargo test -p id server_config passing on the laptop, merged when the Codex findings gate clears.
Links: packet evidence at main 081d69f (parse.rs claim paths)

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane A shift
Session / ID: task 5050
Found via: queue claim
Task: PR fix(id/server_config): reject blank and whitespace-padded declaration keys (#1824) #4045 opened for issue id(server_config): a blank or whitespace-padded key passes parse — a blank user key fails only mid-provisioning after earlier users are already created, and a padded key silently diverges from the account name it creates #1824: ServerConfig::parse rejects blank and whitespace-padded user/group declaration keys (new ConfigError::InvalidKey), with six unit tests. Verified 6/6 through a temporary public-API harness because the crate's lib-test target does not compile on clean main — that pre-existing break (src/idset.rs ChainExt missing the note field) is filed as issue id: lib tests do not compile — idset.rs ChainExt initializer missing the note field #4044.
Expectation: merge after the Codex findings gate on PR fix(id/server_config): reject blank and whitespace-padded declaration keys (#1824) #4045 clears; the in-crate unit suite runs once issue id: lib tests do not compile — idset.rs ChainExt initializer missing the note field #4044 lands.
Links: PR fix(id/server_config): reject blank and whitespace-padded declaration keys (#1824) #4045 · issue id: lib tests do not compile — idset.rs ChainExt initializer missing the note field #4044

Merge pull request #4045 from developing-today/queue/5050-1824-blank-…

🤖 Agent note · done

Agent: queue worker (repo-worker-code), lane A shift
Session / ID: task 5050
Found via: queue claim
Task: Issue id(server_config): a blank or whitespace-padded key passes parse — a blank user key fails only mid-provisioning after earlier users are already created, and a padded key silently diverges from the account name it creates #1824 fixed and merged: PR fix(id/server_config): reject blank and whitespace-padded declaration keys (#1824) #4045 (merge commit f3e9c19) — ServerConfig::parse rejects blank and whitespace-padded user/group declaration keys via the new ConfigError::InvalidKey, with six unit tests in parse.rs. Codex review on PR fix(id/server_config): reject blank and whitespace-padded declaration keys (#1824) #4045 completed with no findings. Verification ran 6/6 through a temporary public-API harness because the crate's lib-test target does not compile on clean main; that pre-existing break is filed as issue id: lib tests do not compile — idset.rs ChainExt initializer missing the note field #4044 and the in-crate suite should be re-run once it lands.
Expectation: done; task 5050 completed as fixed_merged.
Links: PR fix(id/server_config): reject blank and whitespace-padded declaration keys (#1824) #4045 · issue id: lib tests do not compile — idset.rs ChainExt initializer missing the note field #4044

Navigation Menu

Repository navigation

id(server_config): a blank or whitespace-padded key passes parse — a blank user key fails only mid-provisioning after earlier users are already created, and a padded key silently diverges from the account name it creates #1824

id(server_config): a blank or whitespace-padded key passes parse — a blank user key only fails mid-provisioning, after earlier users are already created

Summary

Why it matters

Evidence (verified this run, main `528886e`)

Acceptance criteria

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(server_config): a blank or whitespace-padded key passes parse — a blank user key fails only mid-provisioning after earlier users are already created, and a padded key silently diverges from the account name it creates #1824

Description

id(server_config): a blank or whitespace-padded key passes parse — a blank user key only fails mid-provisioning, after earlier users are already created

Summary

Why it matters

Evidence (verified this run, main 528886e)

Acceptance criteria

Activity

developing-today commented on Oct 28, 2026

dezren39 commented on Oct 28, 2026

9 remaining items

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Evidence (verified this run, main `528886e`)