Clarify public-org audit rule: component names are acceptable, identity material is not #12

Open
opened 2026-07-05 18:31:15 +01:00 by vnprc-agent · 0 comments
Contributor

User story: So that I can review public-source audits consistently, the guidance must distinguish acceptable component names from credentials, identity material, and private addressing that must stay out of public repos.

Part of the "Agent isolation & security boundary" arc.


allod.md states the audit rule for migrating a repo to the public org as: "no plaintext secrets, no personal identifiers, and no host-specific private addressing."

"No personal identifiers" is ambiguous. A dev-plan review pass derived the stricter form "no real inventory values, IPs, usernames, or identity material may leak into committed source or fixtures" from it and flagged real VM names and usernames in nexus test fixtures (the nostr privacy-VM name/username pairing and the allod-dev agent row) as a finding. Owner ruling: name-level metadata of components slated for public release — VM names, VM usernames, agent account names — is acceptable in public source, fixtures, and history. The rule's intent is to block plaintext secrets, identity and key material, credentials, and host-specific private addressing.

Proposed clarified wording for the audit rule in allod.md (starting point; final wording is the implementer's call):

Audit rule before migrating a repo to the public org: no plaintext secrets, no identity or key material, no credentials, no personal identifiers, and no host-specific private addressing (real IPs, internal hostnames). Component names slated for public release — VM names, VM usernames, agent account names — are not personal identifiers and are acceptable. Age-encrypted blobs are fine in public repos by design.

Decision criterion for future reviews: flag a source or fixture value only when it exposes key material, credentials, or private addressing, or when the named component is not slated for public release.

Refs vnprc/notes#44 (rotation-script-consolidation plan review, pass 4, where the over-strict derivation was applied and overruled).

**User story:** So that I can review public-source audits consistently, the guidance must distinguish acceptable component names from credentials, identity material, and private addressing that must stay out of public repos. _Part of the "Agent isolation & security boundary" arc._ --- `allod.md` states the audit rule for migrating a repo to the public org as: "no plaintext secrets, no personal identifiers, and no host-specific private addressing." "No personal identifiers" is ambiguous. A dev-plan review pass derived the stricter form "no real inventory values, IPs, usernames, or identity material may leak into committed source or fixtures" from it and flagged real VM names and usernames in nexus test fixtures (the nostr privacy-VM name/username pairing and the allod-dev agent row) as a finding. Owner ruling: name-level metadata of components slated for public release — VM names, VM usernames, agent account names — is acceptable in public source, fixtures, and history. The rule's intent is to block plaintext secrets, identity and key material, credentials, and host-specific private addressing. Proposed clarified wording for the audit rule in `allod.md` (starting point; final wording is the implementer's call): > Audit rule before migrating a repo to the public org: no plaintext secrets, no identity or key material, no credentials, no personal identifiers, and no host-specific private addressing (real IPs, internal hostnames). Component names slated for public release — VM names, VM usernames, agent account names — are not personal identifiers and are acceptable. Age-encrypted blobs are fine in public repos by design. Decision criterion for future reviews: flag a source or fixture value only when it exposes key material, credentials, or private addressing, or when the named component is not slated for public release. Refs vnprc/notes#44 (rotation-script-consolidation plan review, pass 4, where the over-strict derivation was applied and overruled).
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/memory#12
No description provided.