ngit stage-2 key unlocated (the #471/#473 recurrences) — safe test-key design inside; production recovery decision owed (A: find / B: re-anchor / C: add maintainer)

Aperta
  • Qualcosa non va?
#761 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
git, go, shell
Ambito
devops, release

Direzione di ricerca

Start with scripts/ngit-ci-release.sh and the key handling described in the issue; inspect AGENTS.md and the release-lane notes for the publisher key and release gate. The proposed scratch-repo test needs a separate throwaway key and an ngit repo it owns, while the production path still requires a maintainer decision among locating, re-anchoring, or adding a key. Done means stage-2 mechanics are tested safely and the production key path is decided; rc1 is already waiting on that decision.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs:human-review

The ngit stage-2 key situation — the real blocker, and a safe test-key design

The problem: scripts/ngit-ci-release.sh authenticates mirror pushes with an nsec from ~/.hermes/.ngit-new-key (KEYFILE) — injected as git config nostr.nsec for git-remote-nostr pushes to the mirror. That file exists on no reachable machine, the maintainer confirms they don't have one at hand, and this is not the first time: #471 ("stage 2 + announce blocked on operator key — nobody driving") and #473 ("no maintainer nsec off-CobradorWave") are the same bottleneck recurring. The rc1 tag is pushed and waiting; stage 2 cannot run without resolving this.

What the key actually is

The mirror repo (relay.ngit.dev/npub1x677…/tollgate-module-basic-go) is owned by the npub in its clone URL. Push rights presumably bind to that owner key (or maintainers configured beside it). The CI publisher key (6cfc53…, per AGENTS.md) signs release events — a different, dedicated role. So stage 2 needs: a key the production mirror accepts for pushes.

The safe test-key design (answering "should we just make one for testing?")

Yes — with the scope bounded so its insecurity is structural, not procedural:

  1. Never add it to the production mirror. A throwaway key with no maintainer rights on the real repo can't produce fake release refs no matter who steals it — the insecurity of a test key is exactly proportional to what it can write.
  2. Test against a scratch mirror the test key OWNS. ngit repos are per-npub: generate nsec-test, push a scratch repo (…/npub<test>/tollgate-ci-test), point the stage-2 script's ngit remote at it, and run the full orchestration (ref pushes → shard triggers → verdict reads → resume paths) against a harmless target. This exercises everything except production auth — which is the one thing it deliberately cannot test.
  3. Marking, three layers: the keyfile carries a header comment (# THROWAWAY — pipeline mechanics test only; never a maintainer key; delete after use) — the script greps the nsec out and never strips comments, so the marker travels with the key; the scratch repo name says ci-test; any events it could ever sign land under its own unknown npub, which no consumer follows.
The production path (the actual decision owed)
  • Option A — locate the original key. The ~/.hermes/ path hints at the tool that held it; candidates: the pre-CobradorWave workstation, password manager, the ngit onboarding notes. Cheapest if it exists.
  • Option B — re-anchor the mirror under a new dedicated key (the AGENTS.md doctrine: per-purpose keys, never identity keys): mint a fresh release key, re-announce the repo (kind 30617) under it, update the README clone URLs + CI remotes, record the new pubkey in AGENTS.md beside the publisher keys. Bigger, release-critical, and needs whoever signs announcements today (36bdeb…).
  • Option C — confirm the mirror accepts secondary maintainer keys and add the new one alongside (if ngit supports it) — smallest change, same result.

Recommendation: do the scratch-repo test-key NOW (it validates the whole stage-2 mechanics while the key question resolves), and decide A/B/C before v0.6.0-final — rc1's publish can wait for the owner word per the release lane's own gate.

Lingua principale
Go
Stelle
12
Fork
14
Merge medio
3g 20h
PR unite (30g)
261

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenTollGate/tollgate-module-basic-go

Tutte le issue di OpenTollGate/tollgate-module-basic-go

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.