40 — Operational Security

How the people who hold Locara’s trust-root credentials operate safely. The signing keys, registrar account, Apple Developer Program, GitHub org, and CI infrastructure are the project’s security perimeter. If any one is compromised, every Locara app is at risk.

This document covers identity disclosure, key custody, succession, and incident-response posture for the trust group.

Why this matters

Locara’s pitch is “secure by default.” That promise dies if the people running the project can’t be trusted, can’t be reached, or can’t recover from compromise. Engineering security (capability enforcement, sandboxing, signing) only matters if the operational layer underneath is sound.

This document complements 13-security-privacy.md (user-facing security) and 14-trust-safety.md (registry-side trust). It’s about the people, not the code.

Project lead identity

The project lead is publicly identified. The architecture demands it: an anonymous person with control over signing keys for thousands of apps is a non-starter for trust.

What’s public

• Real legal name.
• Professional context — CV, prior work, public speaking / writing.
• Verified GitHub identity with GPG-signed commits.
• Long-form public writing (devlog, blog, talks).
• Country / jurisdiction of operation (not specific address).
• Public contact email (project-related).
• PGP public key fingerprint for security disclosure.
• Active social presence that’s identifiably the same person (X / Mastodon / LinkedIn — pick at least one).
• Existence and identity of a backup contact (a named maintainer who can be reached in an emergency).
• Existence of operational-security measures (hardware security keys, escrow, succession). Specific details private; existence public.

What’s not public

• Home address.
• Personal phone number.
• Family members’ names or info.
• Date of birth.
• Specifics of escrow custody (third party identity, location).

The model is “verifiable real person, professionally accountable, operationally secure” — not “publicly known to a personal-safety risk.”

The trust group

Per ADR 0003, commit access to canonical Locara repositories is restricted to a small trust group.

Initially this is the project lead alone. Adding members happens by consensus per 23-governance.md.

Trust group members must:

• Be publicly identifiable (same standard as the project lead).
• Have demonstrated security judgment (sustained contributions, no incidents).
• Use 2FA + hardware security keys for all relevant credentials.
• Sign their commits with GPG keys registered with the project.
• Read + acknowledge this document.

Membership is publicly listed; additions and removals are documented in ADRs.

Credentials inventory

The project’s trust-root credentials, who holds them, and how they’re protected:

Credential	Holder (initially)	Storage	Backup
Apple Developer Program account	Project lead	Apple ID + 2FA + recovery key	Escrow
Apple Developer ID Application cert	CI Secret (GitHub Actions) + project lead’s keychain	Hardware-security-key-protected	Escrow
Locara Sigstore identity key	CI environment	Short-lived; rotated per build	Sigstore log is the backup
Domain registrar account	Project lead	2FA + hardware key	Escrow
GitHub organization owner	Project lead	2FA + hardware key	Backup owner is the trust-group successor
Cloudflare account (R2 + Pages + DNS)	Project lead	2FA + hardware key	Escrow
Postgres / Neon admin	Project lead	2FA	Escrow
Email (security@, dmca@, etc.)	Project lead	2FA	Escrow
PGP key for signed announcements	Project lead	Hardware-security-key-only	Revocation cert escrowed
GitHub-Actions Secrets vault	Project lead	GitHub-managed	Re-creatable via GitHub admin

Hardware security keys

Required for high-value operations:

• Code signing (Apple Dev cert + Sigstore identity).
• Registrar / Cloudflare / GitHub admin actions.
• Project-lead GitHub commits to canonical repos.

The project owns at least two YubiKeys (or equivalent) per trust group member: one daily-use, one stored offline as backup. Stored offline keys are physically separated from the daily-use one (different building, different person if possible).

2FA mandatory

Every credential that supports it has 2FA enabled. Phone-based SMS 2FA is not acceptable (SIM-swap risk); we require app-based TOTP or hardware security key.

Key escrow + succession

If the project lead is incapacitated or unreachable, the project must continue. Escrow + succession make that possible.

What’s escrowed

• Recovery codes for: Apple, GitHub, registrar, Cloudflare, Postgres, email.
• Backup hardware security key physical access.
• Apple Developer Program transfer instructions (Apple’s procedure for incapacitated developers).
• GPG private key (encrypted, with passphrase escrowed separately).
• Documentation of how to use all of the above.

Where it’s escrowed

Two-of-three model:

1. Trusted attorney or fiscal sponsor holds physical/encrypted copies.
2. Designated successor maintainer has access to half (or all) the recovery process.
3. Optional: a digital-rights nonprofit (e.g., Software Freedom Conservancy) as a tertiary holder.

Any two of the three together can recover the credentials. Single-holder compromise doesn’t expose the keys.

Succession activation

Per 23-governance.md:

1. Maintainers (including the designated successor) confirm incapacitation.
2. Convene to confirm succession trigger (vote if needed).
3. Activate escrow recovery process.
4. New project lead takes over credentials.
5. Public announcement on the website + via social channels.
6. Each trust-group member rotates their access tokens.

Drills

Quarterly:

• Simulate “project lead unreachable for 7 days.”
• Designated successor walks through the recovery process (without actually rotating).
• Document gaps; update this doc.

Without drills, the escrow plan is theater.

Security disclosure flow

Reports go to security@<domain> (encrypted with the published PGP key when sensitive).

Triage SLA:

• Critical: 24-hour acknowledgment, 7-day patch window.
• High: 48-hour acknowledgment, 30-day patch window.
• Medium / Low: 7-day acknowledgment, next-release patch.

Coordinated disclosure: standard 90-day embargo unless severity demands faster.

Acknowledgment includes:

• Confirmation of receipt.
• Initial severity assessment.
• Expected timeline.
• Liaison contact (project lead unless conflict-of-interest).

Reporters are credited publicly (with consent) in the advisory + the postmortem.

Bug bounty (future)

Phase 4+ if user base justifies. Until then, security work is on the project lead + trusted-contributor goodwill.

When activated:

• Hosted on huntr / GitHub Security Bounty / similar.
• Scope explicitly defined (infrastructure, framework code, registry pipeline; not third-party Locara apps unless they opt in).
• Reward tiers transparent.
• Reporters’ identity protected unless they consent to disclosure.

Phishing + social engineering posture

Trust-group members are targets. Mitigations:

• No credential disclosure over phone or video call, ever, regardless of who appears to be calling.
• All security-related communication confirmed via signed email + a secondary channel (Signal, in-person, etc.).
• No production credential entry on phones. Phones are not safe enough for trust-root operations; desktop-only with hardware security key.
• Verified out-of-band for high-impact actions: a request to revoke a key gets confirmed via a different channel before action.
• Awareness training for trust-group members. Not formal; a checklist + reading list.

Public artifacts

The website hosts:

• <domain>/security — security policy, PGP key, contact info, advisories index.
• <domain>/people — trust group identities + verified profiles.
• <domain>/escrow-overview — public summary of the escrow + succession model (without specifics).

These are public commitments. Living up to them is the operational requirement.

Signed announcements

For high-trust communications (key rotation, security advisories, incident postmortems, succession events), the project lead signs the announcement with their GPG key. Users can verify the signature against the published fingerprint.

This protects against impersonation: even if the website is compromised, signed announcements can be verified independently.

What this looks like for v1 (single project lead)

• Identity disclosure as above. Public name, GitHub, blog, country.
• Hardware security keys + 2FA on everything from day one.
• Escrow established before phase 0 closes (lawyer + designated trusted person).
• PGP key generated, fingerprint published, revocation cert in escrow.
• Quarterly drills documented.
• Trust group: project lead alone. Single point of failure mitigated by escrow + succession.

When the trust group expands (phase 4+), this doc updates with member-specific details.

Open questions

• (open) Specific escrow partners (lawyer? nonprofit? both?). Pending entity formation.
• (open) Whether to use Sigstore’s transparency log alone or additionally maintain our own append-only log.
• (open) Whether the project lead’s location (city / region) should be public for accountability, or kept country-level for safety. Lean country-level.
• (open) Code-signing key rotation cadence. Annually with manual trigger, or automated with shorter cadence?
• (open) Should we maintain a “canary” page (warrant-canary-style) declaring no government compulsion received? Common in privacy-focused projects; small overhead; useful signal.

Related documents

• Governance + succession
• Crisis Runbook — what to do during incidents.
• Trust & Safety — registry / app-side trust.
• Security & Privacy — user-facing security.
• Build pipeline — where the keys are used.
• ADR 0003 — restricted commit access.

Cross-references from other docs

This doc is referenced from:

• 16-build.md — for key custody.
• 13-security-privacy.md — for the operational layer.
• 27-crisis-runbook.md — for incident response.
• 23-governance.md — for succession.