Locara

47 — Publisher Account Recovery

What happens when a Locara publisher loses access to their account: lost 2FA device, compromised credentials, abandoned account, etc. This is distinct from 40-operational-security.md, which covers the trust group’s own credentials.

Account types + their recovery posture

Different accounts have different recovery paths because they have different blast radii.

AccountBlast radiusRecovery posture
Publisher (regular)Their own apps’ update authorityAutomated recovery with verification
Publisher (verified domain)Their own apps + the verified-publisher badgeSame + DNS re-verification
Trust-group memberLocara framework’s signing keysManual + multi-party verification
Project leadEverythingPer 40-operational-security.md

This document covers the first two. Trust-group recovery is in 40.

Authentication baseline

Locara publisher accounts authenticate via:

  1. GitHub OAuth (primary identity).
  2. 2FA mandatory (TOTP via authenticator app; hardware key recommended for high-impact publishers).
  3. Publisher signing key (Ed25519, generated by Locara, used to authenticate submissions).

Three things to lose. Each loss has its own recovery path.

Loss scenarios + recovery flows

Scenario A: Lost 2FA device, GitHub still works

Most common scenario. User has a new phone; their old TOTP authenticator is gone.

Recovery flow:

  1. User logs in via GitHub OAuth (still works since they have GitHub access).
  2. System detects 2FA is enabled but not satisfied; presents recovery options.
  3. Backup codes — every account is issued 10 backup codes at 2FA setup. User uses one.
  4. Reset 2FA + re-enroll — new TOTP secret issued; backup codes regenerated.
  5. No re-verification of GitHub identity required because GitHub OAuth already handled that.
  6. Account is normal again.

If user lost backup codes too:

  1. Email-based recovery — sent to the email on file from GitHub (assumed under user’s control). Time-delayed (24 hours) to defeat live attacks.
  2. Identity-prove flow — user signs a recovery challenge with the publisher signing key (if they still have it).
  3. Last resort: manual review by Locara trust group, with proof of identity (e.g., signing a commit on their GitHub from a known fingerprint).

Cool-down on recovery: for 7 days after recovery, certain operations are disabled (publishing capability-expanding updates) to detect and reverse account hijack via this flow.

Scenario B: Lost GitHub access (account suspended / hijacked at GitHub)

User’s GitHub account is the OAuth source. Without it, normal recovery is broken.

Recovery flow:

  1. User contacts Locara via security email (security@locara.app) with proof of identity (e.g., their PGP key signing a recovery request, prior emails, social verification).
  2. Locara trust group reviews the request manually.
  3. If satisfied: account access restored via alternate-OAuth-provider linking (GitLab, Codeberg, etc.) or via direct credential reset.
  4. The user’s apps are flagged “publisher in recovery” for a 7-day cool-down.
  5. User regains normal control after the cool-down + standard authentication.

Manual review SLA: 7 days target for response (volunteer-run trust group; not a 24/7 service).

Scenario C: Compromised account (active hijacker has the credentials)

Discovered via:

  • Sudden capability changes in submitted updates.
  • Anomalous IP / location for publish actions.
  • Direct user report.
  • Trust-group spot review.

Response flow:

  1. Immediate freeze. Trust group disables the publisher account; all in-flight submissions paused.
  2. Capability cool-down on any unactivated capability changes (per 13-security-privacy.md) is extended to 30 days for the affected apps.
  3. Public security advisory published if user-impacting.
  4. Investigation. Determine scope: are recent submissions tampered? Were keys leaked beyond just account?
  5. Recovery. Legitimate user proves identity (per Scenario B); credentials reset; signing keys rotated.
  6. Post-recovery. Affected apps receive a “security update” version ratcheting changes; users notified to install.
  7. Postmortem published within 30 days.

Scenario D: Lost publisher signing key

The publisher’s Ed25519 key was used to sign submissions. If lost, the user can’t submit new versions but their existing apps remain installed.

Recovery flow:

  1. User logs in normally (GitHub + 2FA still work).
  2. Account dashboard offers “Generate new signing key.”
  3. User generates new key, registers it with Locara, optionally revokes old key (if compromised, not just lost).
  4. New submissions use new key.
  5. Existing apps unaffected — the publisher signing key authenticates submissions, not artifacts. Artifacts are signed by Locara CI’s key.

This is the lowest-stakes loss. The publisher signing key only authenticates “this commit was authorized by the registered publisher”; it doesn’t sign the binary itself.

Scenario E: Account abandonment

Publisher disappears; doesn’t respond to communications; their apps still have users.

After 90 days of inactivity + 30 days unresponsive to outreach:

  1. Locara trust group can mark the account as “abandoned.”
  2. Apps remain installable + runnable for existing users (no kill-switch).
  3. New installs see a “Publisher inactive” banner on the app page.
  4. Apps cannot receive updates from the original publisher.
  5. After 12 more months, trust group can offer the apps to a new maintainer (via public RFC), provided the original publisher is genuinely unresponsive + the takeover is in users’ interest.

This avoids “abandoned but still on Apple App Store-style” problem where users install apps that haven’t been touched in years.

Automated recovery: what’s required

Each automated recovery path requires the user to demonstrate ≥ 1 of:

FactorWhat
GitHub OAuthLogin with their GitHub account
2FATOTP code from authenticator
Backup codeOne of 10 codes issued at 2FA setup
EmailClick confirmation link sent to email-on-file
Publisher signing keySign a recovery challenge

Recovery flows require at least 2 factors for sensitive operations (capability changes, account deletion). Recovery flows for less-sensitive operations (re-enrolling 2FA) accept 1.

Manual recovery (trust group involvement)

Manual recovery is the escape hatch when all automated paths fail. It’s resource-intensive but necessary for legitimate cases.

Trust group SLA: 7-day response, 30-day resolution target.

Required for manual recovery:

  • Proof of GitHub account ownership history (e.g., signing a commit at a public-known fingerprint).
  • PGP-signed statement of intent, fingerprint matching prior public records.
  • 2+ trusted contributor / community attestations of identity.
  • Cool-down period (7 days) before access is restored, during which Locara monitors for adversarial activity.

Trust group decisions are documented in an internal recovery log + annual public summary (anonymized).

What we don’t do

  • Knowledge-based authentication (“what was your first pet?”). Easily defeated.
  • SMS recovery. SIM-swap risk is too high.
  • Photo ID submission. Heavyweight; not aligned with privacy ethos.
  • Social recovery via designated friends-of-publisher. Cool concept; complexity not justified for v1.
  • Auto-approve unverified emergency requests. Always involves human review.

UX principles

  • Discoverable. “Lost access?” link on the login page; not buried.
  • Honest. “This will take 24+ hours” is better than “Try again later.”
  • Reversible. Cool-down windows let legitimate users undo a malicious recovery.
  • Logged. All recovery actions are logged + the publisher is notified.

What recovery looks like for the user

┌────────────────────────────────────────────────────────┐
│ Account Recovery                                       │
│                                                        │
│ Pick what you have access to:                          │
│                                                        │
│ ○ My GitHub account works, but I lost 2FA             │
│ ○ My GitHub account is locked / hijacked              │
│ ○ I think my account was compromised                  │
│ ○ I lost my publisher signing key                     │
│ ○ Something else                                      │
│                                                        │
│ [ Continue ]                                           │
└────────────────────────────────────────────────────────┘

Each path leads to a guided flow with clear required steps, expected timelines, and documentation links.

Open questions

  • (open) Should we offer hardware-key-only authentication (no TOTP fallback)? More secure; raises bar for adoption. Probably opt-in for high-impact publishers.
  • (open) Should backup codes be PGP-encrypted at issuance? Adds friction. Probably no; user is told to store them safely.
  • (open) Should automated recovery have rate limits per IP / per account? Probably yes; flag suspicious recovery attempts for trust group review.
  • (open) Should we offer an opt-in “social recovery” (designate trusted maintainers who can vouch for you)? Phase 4+.

Cross-references