Compare commits

..

2 Commits

Author SHA1 Message Date
Hermes Agent
e88a89f34d fix(framework): remediate Codex review findings in VAULT-SECRETS.md
Some checks failed
ci/woodpecker/push/ci Pipeline failed
ci/woodpecker/pr/ci Pipeline failed
Two should-fix findings from automated Codex review:

1. Vault KV v2 policy path — add explicit path for exact top-level
   `secret/data/k3s/<app>` entry alongside the wildcard `/*` sub-path
   rule. Without the exact path, apps reading the top-level secret get
   permission denied from Vault KV v2 even with the wildcard.

2. Go envconfig example — remove unused `os` import from config.go
   snippet (os was only referenced in a comment). Move the main() usage
   to a separate clearly-labelled main.go block to make both snippets
   copy-paste compilable.

Both fixes mirrored to duplicate path:
  guides/ <-> packages/mosaic/framework/guides/

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-22 12:01:29 -05:00
Hermes Agent
373e4558a3 chore(framework): canonize Vault-as-SSOT + ESO-default secrets policy
Some checks failed
ci/woodpecker/push/ci Pipeline failed
ci/woodpecker/pr/ci Pipeline failed
Encodes operator-approved (Jason, 2026-05-22) secrets policy as binding
framework rules across all Mosaic agent sessions and projects.

Changes:
- STANDARDS.md: add "Secrets handling (HARD RULE)" subsection under
  Non-Negotiables — Vault as SSOT, ESO bridge as default, Direct-Vault
  opt-in only, forbidden ${VAR:-default} for required values, forbidden
  .env in prod, required startup schema validation
- VAULT-SECRETS.md: add four new sections — architecture decision matrix
  (ESO vs Direct-Vault), full ESO bridge worked example (Vault path +
  ExternalSecret + Deployment YAML + zod/pydantic/Go validators),
  Direct-Vault opt-in pattern (AppRole provisioning + ESO bootstrap
  for chicken-and-egg), and forbidden patterns CI lint targets
- BOOTSTRAP.md: add "Secrets Bootstrap" required subsection with
  checklist for new apps (Vault path, README docs, ExternalSecret,
  secretKeyRef, schema validator, Direct-Vault justification)

All duplicate file paths kept in sync (md5-equal pairs):
  guides/ <-> packages/mosaic/framework/guides/
  packages/mosaic/framework/defaults/STANDARDS.md (single copy in repo)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-22 11:58:27 -05:00
9 changed files with 798 additions and 424 deletions

View File

@@ -1,31 +0,0 @@
# Scratchpad: t_301e4e3b pr-merge.sh Gitea empty-uid fallback
## Task
Implement a narrow hardening in `packages/mosaic/framework/tools/git/pr-merge.sh` so Gitea merges recover from the known non-interactive `tea pr merge` identity failure: `user does not exist [uid: 0, name: ]`.
## Constraints
- Preserve Mosaic policy gates: squash-only, base branch `main`, queue guard unless explicitly skipped.
- Preserve the existing authenticated Gitea API fallback when no tea login exists.
- Do not fallback on arbitrary tea failures.
- Do not expose tokens or credential-bearing remotes.
- Scope is limited to the merge wrapper plus focused test/support/scratchpad files.
## External issue
- Gitea issue #520: Harden pr-merge.sh Gitea empty-uid fallback
## Plan
1. Add a focused shell regression harness with mocked `tea` and `curl` proving the known empty uid/name failure must fall back to Gitea API.
2. Watch the harness fail on current code.
3. Implement helper functions in `pr-merge.sh` for redacted command display, known failure classification, and authenticated Gitea API merge fallback.
4. Keep unknown `tea` failures blocking by replaying stderr and exiting non-zero.
5. Run syntax, shellcheck if available, focused regression, and repo quality gates before push/PR.
## Session log
- 2026-05-22: Read Kanban context, Mosaic global/repo instructions, created isolated branch `fix/t_301e4e3b-pr-merge-gitea-empty-uid`, and opened Gitea issue #520 using the Mosaic issue wrapper/API fallback.
- 2026-05-22: Added regression harness and watched it fail on current behavior with `user does not exist [uid: 0, name: ]`; implemented narrow fallback and verified known-empty-identity fallback, arbitrary tea failure blocking, and no-tea-login API fallback paths.
- 2026-05-22: Validation passed for `bash -n`, `shellcheck -x`, focused shell harness, `pnpm typecheck`, `pnpm lint`, `pnpm format:check`, and `pnpm --filter @mosaicstack/mosaic test`. Full `pnpm test` exposed an out-of-scope gateway DB setup failure (`relation "messages" does not exist`) in `apps/gateway/src/__tests__/cross-user-isolation.test.ts`.

View File

@@ -1,48 +0,0 @@
# t_5aab9cc8 — pr-merge.sh eval injection remediation
## Objective
Remediate PR #521 review blocker: `packages/mosaic/framework/tools/git/pr-merge.sh` must reject non-numeric PR numbers before metadata lookup/merge and must not use `eval` for GitHub merge execution.
## Scope
- Shell wrapper only: `packages/mosaic/framework/tools/git/pr-merge.sh`
- Focused regression harness: `packages/mosaic/framework/tools/git/test-pr-merge-gitea-empty-uid.sh`
- No API/frontend/infra surfaces.
## Acceptance Criteria
- AC1: `PR_NUMBER` is validated as digits-only immediately after required-argument parsing, before metadata lookup.
- AC2: GitHub merge path uses a quoted argv array, not command-string construction plus `eval`.
- AC3: Focused tests prove PR-number metacharacters are rejected and cannot execute injected shell commands on GitHub path.
- AC4: Focused tests prove PR-number metacharacters are rejected on Gitea path before tea/curl merge calls.
- AC5: Existing Gitea empty-uid fallback behavior remains green.
- AC6: Syntax, shellcheck where available, focused harness, and relevant repo gates are rerun or absence documented.
## Plan
1. Add failing regression tests for GitHub eval injection and Gitea invalid PR rejection.
2. Implement fail-closed PR number validation before metadata lookup.
3. Replace GitHub `eval` command with argv array execution.
4. Run required validation and update this scratchpad with evidence.
5. Commit, queue-guard, push branch, update PR #521.
## TDD Log
- RED: `AGENT_WORK_ROOT="$HERMES_KANBAN_WORKSPACE/work" bash packages/mosaic/framework/tools/git/test-pr-merge-gitea-empty-uid.sh` failed on vulnerable code with `Expected GitHub metacharacter PR number to be rejected` and showed the injected PR number reached the GitHub merge path.
- GREEN: Added digits-only validation before metadata lookup and replaced GitHub `eval` with an argv array. The focused harness now passes and verifies invalid PR numbers are rejected before GitHub `gh` calls and before Gitea `tea`/`curl` calls.
## Validation Evidence
- PASS: `AGENT_WORK_ROOT="$HERMES_KANBAN_WORKSPACE/work" bash -n packages/mosaic/framework/tools/git/pr-merge.sh packages/mosaic/framework/tools/git/test-pr-merge-gitea-empty-uid.sh`
- PASS: `shellcheck -x packages/mosaic/framework/tools/git/pr-merge.sh packages/mosaic/framework/tools/git/test-pr-merge-gitea-empty-uid.sh`
- PASS: `AGENT_WORK_ROOT="$HERMES_KANBAN_WORKSPACE/work" bash packages/mosaic/framework/tools/git/test-pr-merge-gitea-empty-uid.sh`
- PASS: `pnpm --filter @mosaicstack/mosaic... build`
- PASS: `pnpm --filter @mosaicstack/mosaic lint`
- PASS: `pnpm --filter @mosaicstack/mosaic typecheck`
- PASS: `pnpm --filter @mosaicstack/mosaic test` — 32 files / 291 tests passed.
- REVIEW: `/home/hermes/.config/mosaic/tools/codex/codex-code-review.sh --uncommitted` could not run due Codex 401 Unauthorized. Independent delegate review completed read-only with PASS / no blockers; non-blocking suggestion to assert GitHub mock log remains empty was applied.
## Risks / Blockers
- No active blockers.

View File

@@ -453,6 +453,26 @@ Initialize standard labels and the first pre-MVP milestone:
---
## Secrets Bootstrap (Required for Every New App)
Every new application MUST complete the following secrets bootstrap before deploying to any non-local environment. This is a hard gate — deployment without completed secrets bootstrap is forbidden.
### Secrets bootstrap checklist
- [ ] Vault path created: `vault kv put secret/k3s/<app>/ ...` with all required secret fields
- [ ] Required secrets listed in project README under a "Secrets architecture" section, including:
- Vault path(s) used
- All required secret keys and their purpose
- Whether the app uses ESO bridge (default) or Direct-Vault (opt-in, with justification)
- [ ] `external-secret.yaml` manifest committed to repo's `deploy/` or `k8s/` directory
- [ ] Deployment YAML references the synced k8s Secret via `secretKeyRef` (not raw env vars or `.env` files)
- [ ] App startup has schema-based validation for all required env vars (zod / pydantic / envconfig equivalent) that exits non-zero on missing required values
- [ ] Direct-Vault opt-in (if applicable): justification documented in README + AppRole provisioned + bootstrap credentials stored in Vault and synced via a separate `ExternalSecret`
See `~/.config/mosaic/guides/VAULT-SECRETS.md` for full worked examples of the ESO bridge pattern, the Direct-Vault opt-in pattern, and the forbidden antipatterns.
---
## Checklist
After bootstrapping, verify:

View File

@@ -203,3 +203,374 @@ Error: token expired
3. **Audit logging** - All access is logged; act accordingly
4. **No local copies** - Don't store secrets in files or env vars long-term
5. **Rotate on compromise** - Immediately rotate any exposed secrets
---
## Secrets Architecture Decision Matrix
Use this table to choose between the ESO bridge (default) and Direct-Vault (opt-in) patterns for every new app or integration.
| Factor | ESO Bridge (default) | Direct-Vault (opt-in) |
| --- | --- | --- |
| **Use-case** | All static secrets (DB creds, API keys, signing keys, OAuth secrets) | Dynamic creds with short TTLs (DB rotation, AWS STS, PKI), per-request audit trails, or lease renewal mid-pod-lifecycle |
| **App code change** | None — reads standard env vars via `secretKeyRef` | Requires Vault client (`hvac`, `node-vault`, `vault/api`) in application code |
| **Secret rotation** | ESO re-syncs on Vault write; pod restart or secret refresh picks up new value | App manages lease renewal or re-auth within the running process |
| **Audit granularity** | Access logged at Vault when ESO syncs; no per-request app audit | Every app request to Vault is a separate audit log entry |
| **Operational burden** | Low — ESO handles polling, sync, and k8s Secret lifecycle | Higher — app must handle auth, lease renewal, error paths, and token rotation |
| **Justification required?** | No — this is the default | Yes — document in project README under "Secrets architecture" |
| **Example use cases** | Web app DB password, OAuth client secret, JWT signing key, API token | HashiCorp DB secrets engine with 15-min TTL leases, AWS STS assume-role, Vault PKI short-lived certs |
**Decision rule:** If you are unsure, use ESO. Only justify Direct-Vault when the secret cannot be safely stored in a k8s Secret (too short-lived, per-request TTL required, or mid-lifecycle renewal needed).
---
## ESO Bridge Pattern (Default)
This is the required default for all k8s workloads. Follow this exact pattern unless a documented dynamic-secrets requirement justifies Direct-Vault.
### 1. Provision Vault path
```bash
# Write the secrets for the app (run once; use IaC/Terraform for repeatable provisioning)
vault kv put secret/k3s/<app> \
db_password="..." \
api_key="..." \
jwt_secret="..."
```
Use the canonical path structure: `secret/k3s/<app>` for k3s cluster workloads.
### 2. ExternalSecret manifest
Commit this to the repo's `deploy/` or `k8s/` directory:
```yaml
# deploy/external-secret.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: <app>-secrets
namespace: <namespace>
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend # ClusterSecretStore name — verify with cluster admin
kind: ClusterSecretStore
target:
name: <app>-secrets # k8s Secret name that will be created
creationPolicy: Owner
data:
- secretKey: DB_PASSWORD # key in the k8s Secret
remoteRef:
key: secret/k3s/<app> # Vault path
property: db_password # field within the Vault secret
- secretKey: API_KEY
remoteRef:
key: secret/k3s/<app>
property: api_key
- secretKey: JWT_SECRET
remoteRef:
key: secret/k3s/<app>
property: jwt_secret
```
### 3. Deployment manifest — reference synced k8s Secret
```yaml
# deploy/deployment.yaml (env section)
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: <app>-secrets # matches ExternalSecret target.name
key: DB_PASSWORD
- name: API_KEY
valueFrom:
secretKeyRef:
name: <app>-secrets
key: API_KEY
- name: JWT_SECRET
valueFrom:
secretKeyRef:
name: <app>-secrets
key: JWT_SECRET
- name: PORT
value: "3000" # safe-default: non-secret, no Vault needed
```
### 4. App-side schema validation — TypeScript (zod)
Validate all required env vars at startup. Exit non-zero on missing values.
```typescript
// src/env.ts
import { z } from 'zod';
const envSchema = z.object({
DB_PASSWORD: z.string().min(1, 'DB_PASSWORD is required'),
API_KEY: z.string().min(1, 'API_KEY is required'),
JWT_SECRET: z.string().min(32, 'JWT_SECRET must be at least 32 chars'),
PORT: z.coerce.number().default(3000),
NODE_ENV: z.enum(['development', 'production', 'test']).default('production'),
});
const result = envSchema.safeParse(process.env);
if (!result.success) {
console.error('Missing or invalid environment variables:');
console.error(result.error.flatten().fieldErrors);
process.exit(1);
}
export const env = result.data;
```
### 4b. App-side schema validation — Python (pydantic)
```python
# src/config.py
from pydantic_settings import BaseSettings, SettingsConfigDict
class Settings(BaseSettings):
db_password: str
api_key: str
jwt_secret: str
port: int = 3000
node_env: str = "production"
model_config = SettingsConfigDict(env_file=None) # no .env in prod
try:
settings = Settings()
except Exception as e:
import sys
print(f"Missing or invalid environment variables: {e}", file=sys.stderr)
sys.exit(1)
```
### 4c. App-side schema validation — Go (envconfig)
```go
// config/config.go
package config
import (
"fmt"
"github.com/kelseyhightower/envconfig"
)
type Config struct {
DBPassword string `envconfig:"DB_PASSWORD" required:"true"`
APIKey string `envconfig:"API_KEY" required:"true"`
JWTSecret string `envconfig:"JWT_SECRET" required:"true"`
Port int `envconfig:"PORT" default:"3000"`
}
func Load() (*Config, error) {
var cfg Config
if err := envconfig.Process("", &cfg); err != nil {
return nil, fmt.Errorf("invalid environment: %w", err)
}
return &cfg, nil
}
```
In your `main.go`:
```go
cfg, err := config.Load()
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
```
---
## Direct-Vault Opt-In Pattern
Use this pattern ONLY when a documented dynamic-secrets requirement applies (DB rotation with short TTLs, AWS STS, PKI, per-request audit). Document the justification in the project README under "Secrets architecture" before implementing.
### When it is justified
- Vault DB secrets engine with lease TTLs shorter than a typical pod lifecycle (< 1 hour)
- AWS STS assume-role tokens generated per-request
- Vault PKI short-lived certificates (< 24 hours) that must be renewed within a running pod
- Per-request audit trail requirement (each app call must appear separately in Vault audit log)
### Provision an AppRole for the app
```bash
# Enable AppRole auth (if not already enabled)
vault auth enable approle
# Create a Vault policy for the app
# Note: KV v2 paths require both the exact path (for the top-level secret) and the
# wildcard (for sub-paths). Always include both to avoid permission denied errors.
vault policy write <app>-policy - <<EOF
path "secret/data/k3s/<app>" {
capabilities = ["read"]
}
path "secret/data/k3s/<app>/*" {
capabilities = ["read"]
}
path "database/creds/<app>-role" {
capabilities = ["read"]
}
EOF
# Create the AppRole
vault write auth/approle/role/<app>-role \
token_policies="<app>-policy" \
token_ttl=1h \
token_max_ttl=4h \
secret_id_ttl=0
# Retrieve role-id and secret-id
vault read auth/approle/role/<app>-role/role-id
vault write -f auth/approle/role/<app>-role/secret-id
```
### Bootstrap AppRole credentials via ESO (solving the chicken-and-egg problem)
The AppRole `role-id` and `secret-id` are themselves secrets. Store them in Vault at a bootstrap path, then use ESO to sync them into a k8s Secret. The app reads that k8s Secret at startup to authenticate with Vault directly.
```bash
# Store the bootstrap credentials in Vault
vault kv put secret/k3s/<app>-bootstrap \
role_id="<role-id>" \
secret_id="<secret-id>"
```
```yaml
# deploy/external-secret-bootstrap.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: <app>-vault-auth
namespace: <namespace>
spec:
refreshInterval: 24h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: <app>-vault-auth
creationPolicy: Owner
data:
- secretKey: VAULT_ROLE_ID
remoteRef:
key: secret/k3s/<app>-bootstrap
property: role_id
- secretKey: VAULT_SECRET_ID
remoteRef:
key: secret/k3s/<app>-bootstrap
property: secret_id
```
```yaml
# deploy/deployment.yaml (env section for Direct-Vault app)
env:
- name: VAULT_ADDR
value: "https://vault.example.com" # safe-default: non-secret cluster address
- name: VAULT_ROLE_ID
valueFrom:
secretKeyRef:
name: <app>-vault-auth
key: VAULT_ROLE_ID
- name: VAULT_SECRET_ID
valueFrom:
secretKeyRef:
name: <app>-vault-auth
key: VAULT_SECRET_ID
```
### App-side Vault client pattern
```typescript
// src/vault-client.ts — only exists in Direct-Vault apps
import vault from 'node-vault';
import { z } from 'zod';
const bootstrapSchema = z.object({
VAULT_ADDR: z.string().url(),
VAULT_ROLE_ID: z.string().min(1),
VAULT_SECRET_ID: z.string().min(1),
});
const bootstrap = bootstrapSchema.parse(process.env);
const client = vault({ endpoint: bootstrap.VAULT_ADDR });
export async function getVaultClient() {
const { auth } = await client.approleLogin({
role_id: bootstrap.VAULT_ROLE_ID,
secret_id: bootstrap.VAULT_SECRET_ID,
});
client.token = auth.client_token;
return client;
}
```
Document in README under "Secrets architecture": the Vault path, why Direct-Vault is required, and the lease/renewal strategy.
---
## Forbidden Patterns (CI Lint Targets)
The following patterns are forbidden in all Mosaic projects. CI lint SHOULD catch these automatically (implementation tracked separately). Agents MUST NOT introduce these patterns.
### 1. Untagged fallback defaults for required values
```yaml
# FORBIDDEN — required secret with silent fallback
environment:
- DB_PASSWORD=${DB_PASSWORD:-changeme}
- API_KEY=${API_KEY:-}
# REQUIRED — fast-fail on missing required values
environment:
- DB_PASSWORD=${DB_PASSWORD:?DB_PASSWORD is required}
- API_KEY=${API_KEY:?API_KEY is required}
# ALLOWED — true convenience default, tagged
environment:
- PORT=${PORT:-3000} # safe-default: non-secret, app works at any port
```
This applies to: `docker-compose.yml`, k8s manifests, Helm `values.yaml`, any env file committed to git.
### 2. Vault KV calls in application source code (ESO-default projects)
```python
# FORBIDDEN in ESO-default apps — direct Vault client in app source
import hvac
client = hvac.Client(url=os.environ['VAULT_ADDR'])
secret = client.secrets.kv.v2.read_secret_version(path='myapp/db')
```
ESO-default apps read env vars only. Direct-Vault clients belong only in apps with a documented dynamic-secrets justification in README.
### 3. Hardcoded secrets or API keys in committed files
```python
# FORBIDDEN — hardcoded credential
DB_PASSWORD = "supersecret123"
API_KEY = "sk-live-abc123"
```
No exceptions. CI lint must flag any string matching common secret patterns (`password`, `secret`, `api_key`, `token` assigned a literal non-env-var value).
### 4. `.env` files in production deployment paths
```
# FORBIDDEN — .env file in a production deploy path
deploy/.env
k8s/.env
docker/.env
# ALLOWED — local dev only
.env.example # template only, no real values
.env # local dev, must be in .gitignore
```
`.env` files are acceptable in local-dev contexts only and MUST be in `.gitignore`. They are forbidden in any path that a CI pipeline or production deployment process reads directly.

View File

@@ -27,6 +27,16 @@ Master/slave model:
- Do not perform destructive git/file actions without explicit instruction.
- Browser automation (Playwright, Cypress, Puppeteer) MUST run in headless mode. Never launch a visible browser — it collides with the user's display and active session.
### Secrets handling (HARD RULE)
- Vault is the canonical source-of-truth for every secret in every environment. No exceptions.
- For k8s workloads, the default read path is **External Secrets Operator → k8s Secret → env var** (`secretKeyRef`). The app reads standard env vars; no Vault client in app code.
- Direct-Vault clients in application code are **opt-in only**, justified per-app by a documented dynamic-secrets requirement (e.g., DB rotation, AWS STS). Default to ESO. Document the justification in the project's README under "Secrets architecture".
- `${VAR:-default}` fallback syntax in any deployment configuration (compose, k8s manifests, Helm values, env files committed to git) is **forbidden** for required values. Use `${VAR:?VAR is required}` to fast-fail. Defaults are allowed only for true conveniences (e.g. `${PORT:-3000}`) and MUST be tagged `# safe-default: <reason>` so a reviewer can confirm the intent.
- `.env` files in production deployment paths are **forbidden**. `.env.example` and `.env` in local-dev paths are fine.
- App startup MUST validate required secrets against a schema (zod / pydantic / equivalent) and exit non-zero on missing required values. Never run with defaulted weak fallbacks.
- New apps: bootstrap checklist (see `~/.config/mosaic/guides/BOOTSTRAP.md`) MUST include Vault path provisioning + `ExternalSecret` manifest + README declaring the Vault path and required keys.
## Session Lifecycle Contract
- Start: `scripts/agent/session-start.sh`

View File

@@ -453,6 +453,26 @@ Initialize standard labels and the first pre-MVP milestone:
---
## Secrets Bootstrap (Required for Every New App)
Every new application MUST complete the following secrets bootstrap before deploying to any non-local environment. This is a hard gate — deployment without completed secrets bootstrap is forbidden.
### Secrets bootstrap checklist
- [ ] Vault path created: `vault kv put secret/k3s/<app>/ ...` with all required secret fields
- [ ] Required secrets listed in project README under a "Secrets architecture" section, including:
- Vault path(s) used
- All required secret keys and their purpose
- Whether the app uses ESO bridge (default) or Direct-Vault (opt-in, with justification)
- [ ] `external-secret.yaml` manifest committed to repo's `deploy/` or `k8s/` directory
- [ ] Deployment YAML references the synced k8s Secret via `secretKeyRef` (not raw env vars or `.env` files)
- [ ] App startup has schema-based validation for all required env vars (zod / pydantic / envconfig equivalent) that exits non-zero on missing required values
- [ ] Direct-Vault opt-in (if applicable): justification documented in README + AppRole provisioned + bootstrap credentials stored in Vault and synced via a separate `ExternalSecret`
See `~/.config/mosaic/guides/VAULT-SECRETS.md` for full worked examples of the ESO bridge pattern, the Direct-Vault opt-in pattern, and the forbidden antipatterns.
---
## Checklist
After bootstrapping, verify:

View File

@@ -203,3 +203,374 @@ Error: token expired
3. **Audit logging** - All access is logged; act accordingly
4. **No local copies** - Don't store secrets in files or env vars long-term
5. **Rotate on compromise** - Immediately rotate any exposed secrets
---
## Secrets Architecture Decision Matrix
Use this table to choose between the ESO bridge (default) and Direct-Vault (opt-in) patterns for every new app or integration.
| Factor | ESO Bridge (default) | Direct-Vault (opt-in) |
| --- | --- | --- |
| **Use-case** | All static secrets (DB creds, API keys, signing keys, OAuth secrets) | Dynamic creds with short TTLs (DB rotation, AWS STS, PKI), per-request audit trails, or lease renewal mid-pod-lifecycle |
| **App code change** | None — reads standard env vars via `secretKeyRef` | Requires Vault client (`hvac`, `node-vault`, `vault/api`) in application code |
| **Secret rotation** | ESO re-syncs on Vault write; pod restart or secret refresh picks up new value | App manages lease renewal or re-auth within the running process |
| **Audit granularity** | Access logged at Vault when ESO syncs; no per-request app audit | Every app request to Vault is a separate audit log entry |
| **Operational burden** | Low — ESO handles polling, sync, and k8s Secret lifecycle | Higher — app must handle auth, lease renewal, error paths, and token rotation |
| **Justification required?** | No — this is the default | Yes — document in project README under "Secrets architecture" |
| **Example use cases** | Web app DB password, OAuth client secret, JWT signing key, API token | HashiCorp DB secrets engine with 15-min TTL leases, AWS STS assume-role, Vault PKI short-lived certs |
**Decision rule:** If you are unsure, use ESO. Only justify Direct-Vault when the secret cannot be safely stored in a k8s Secret (too short-lived, per-request TTL required, or mid-lifecycle renewal needed).
---
## ESO Bridge Pattern (Default)
This is the required default for all k8s workloads. Follow this exact pattern unless a documented dynamic-secrets requirement justifies Direct-Vault.
### 1. Provision Vault path
```bash
# Write the secrets for the app (run once; use IaC/Terraform for repeatable provisioning)
vault kv put secret/k3s/<app> \
db_password="..." \
api_key="..." \
jwt_secret="..."
```
Use the canonical path structure: `secret/k3s/<app>` for k3s cluster workloads.
### 2. ExternalSecret manifest
Commit this to the repo's `deploy/` or `k8s/` directory:
```yaml
# deploy/external-secret.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: <app>-secrets
namespace: <namespace>
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend # ClusterSecretStore name — verify with cluster admin
kind: ClusterSecretStore
target:
name: <app>-secrets # k8s Secret name that will be created
creationPolicy: Owner
data:
- secretKey: DB_PASSWORD # key in the k8s Secret
remoteRef:
key: secret/k3s/<app> # Vault path
property: db_password # field within the Vault secret
- secretKey: API_KEY
remoteRef:
key: secret/k3s/<app>
property: api_key
- secretKey: JWT_SECRET
remoteRef:
key: secret/k3s/<app>
property: jwt_secret
```
### 3. Deployment manifest — reference synced k8s Secret
```yaml
# deploy/deployment.yaml (env section)
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: <app>-secrets # matches ExternalSecret target.name
key: DB_PASSWORD
- name: API_KEY
valueFrom:
secretKeyRef:
name: <app>-secrets
key: API_KEY
- name: JWT_SECRET
valueFrom:
secretKeyRef:
name: <app>-secrets
key: JWT_SECRET
- name: PORT
value: "3000" # safe-default: non-secret, no Vault needed
```
### 4. App-side schema validation — TypeScript (zod)
Validate all required env vars at startup. Exit non-zero on missing values.
```typescript
// src/env.ts
import { z } from 'zod';
const envSchema = z.object({
DB_PASSWORD: z.string().min(1, 'DB_PASSWORD is required'),
API_KEY: z.string().min(1, 'API_KEY is required'),
JWT_SECRET: z.string().min(32, 'JWT_SECRET must be at least 32 chars'),
PORT: z.coerce.number().default(3000),
NODE_ENV: z.enum(['development', 'production', 'test']).default('production'),
});
const result = envSchema.safeParse(process.env);
if (!result.success) {
console.error('Missing or invalid environment variables:');
console.error(result.error.flatten().fieldErrors);
process.exit(1);
}
export const env = result.data;
```
### 4b. App-side schema validation — Python (pydantic)
```python
# src/config.py
from pydantic_settings import BaseSettings, SettingsConfigDict
class Settings(BaseSettings):
db_password: str
api_key: str
jwt_secret: str
port: int = 3000
node_env: str = "production"
model_config = SettingsConfigDict(env_file=None) # no .env in prod
try:
settings = Settings()
except Exception as e:
import sys
print(f"Missing or invalid environment variables: {e}", file=sys.stderr)
sys.exit(1)
```
### 4c. App-side schema validation — Go (envconfig)
```go
// config/config.go
package config
import (
"fmt"
"github.com/kelseyhightower/envconfig"
)
type Config struct {
DBPassword string `envconfig:"DB_PASSWORD" required:"true"`
APIKey string `envconfig:"API_KEY" required:"true"`
JWTSecret string `envconfig:"JWT_SECRET" required:"true"`
Port int `envconfig:"PORT" default:"3000"`
}
func Load() (*Config, error) {
var cfg Config
if err := envconfig.Process("", &cfg); err != nil {
return nil, fmt.Errorf("invalid environment: %w", err)
}
return &cfg, nil
}
```
In your `main.go`:
```go
cfg, err := config.Load()
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
```
---
## Direct-Vault Opt-In Pattern
Use this pattern ONLY when a documented dynamic-secrets requirement applies (DB rotation with short TTLs, AWS STS, PKI, per-request audit). Document the justification in the project README under "Secrets architecture" before implementing.
### When it is justified
- Vault DB secrets engine with lease TTLs shorter than a typical pod lifecycle (< 1 hour)
- AWS STS assume-role tokens generated per-request
- Vault PKI short-lived certificates (< 24 hours) that must be renewed within a running pod
- Per-request audit trail requirement (each app call must appear separately in Vault audit log)
### Provision an AppRole for the app
```bash
# Enable AppRole auth (if not already enabled)
vault auth enable approle
# Create a Vault policy for the app
# Note: KV v2 paths require both the exact path (for the top-level secret) and the
# wildcard (for sub-paths). Always include both to avoid permission denied errors.
vault policy write <app>-policy - <<EOF
path "secret/data/k3s/<app>" {
capabilities = ["read"]
}
path "secret/data/k3s/<app>/*" {
capabilities = ["read"]
}
path "database/creds/<app>-role" {
capabilities = ["read"]
}
EOF
# Create the AppRole
vault write auth/approle/role/<app>-role \
token_policies="<app>-policy" \
token_ttl=1h \
token_max_ttl=4h \
secret_id_ttl=0
# Retrieve role-id and secret-id
vault read auth/approle/role/<app>-role/role-id
vault write -f auth/approle/role/<app>-role/secret-id
```
### Bootstrap AppRole credentials via ESO (solving the chicken-and-egg problem)
The AppRole `role-id` and `secret-id` are themselves secrets. Store them in Vault at a bootstrap path, then use ESO to sync them into a k8s Secret. The app reads that k8s Secret at startup to authenticate with Vault directly.
```bash
# Store the bootstrap credentials in Vault
vault kv put secret/k3s/<app>-bootstrap \
role_id="<role-id>" \
secret_id="<secret-id>"
```
```yaml
# deploy/external-secret-bootstrap.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: <app>-vault-auth
namespace: <namespace>
spec:
refreshInterval: 24h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: <app>-vault-auth
creationPolicy: Owner
data:
- secretKey: VAULT_ROLE_ID
remoteRef:
key: secret/k3s/<app>-bootstrap
property: role_id
- secretKey: VAULT_SECRET_ID
remoteRef:
key: secret/k3s/<app>-bootstrap
property: secret_id
```
```yaml
# deploy/deployment.yaml (env section for Direct-Vault app)
env:
- name: VAULT_ADDR
value: "https://vault.example.com" # safe-default: non-secret cluster address
- name: VAULT_ROLE_ID
valueFrom:
secretKeyRef:
name: <app>-vault-auth
key: VAULT_ROLE_ID
- name: VAULT_SECRET_ID
valueFrom:
secretKeyRef:
name: <app>-vault-auth
key: VAULT_SECRET_ID
```
### App-side Vault client pattern
```typescript
// src/vault-client.ts — only exists in Direct-Vault apps
import vault from 'node-vault';
import { z } from 'zod';
const bootstrapSchema = z.object({
VAULT_ADDR: z.string().url(),
VAULT_ROLE_ID: z.string().min(1),
VAULT_SECRET_ID: z.string().min(1),
});
const bootstrap = bootstrapSchema.parse(process.env);
const client = vault({ endpoint: bootstrap.VAULT_ADDR });
export async function getVaultClient() {
const { auth } = await client.approleLogin({
role_id: bootstrap.VAULT_ROLE_ID,
secret_id: bootstrap.VAULT_SECRET_ID,
});
client.token = auth.client_token;
return client;
}
```
Document in README under "Secrets architecture": the Vault path, why Direct-Vault is required, and the lease/renewal strategy.
---
## Forbidden Patterns (CI Lint Targets)
The following patterns are forbidden in all Mosaic projects. CI lint SHOULD catch these automatically (implementation tracked separately). Agents MUST NOT introduce these patterns.
### 1. Untagged fallback defaults for required values
```yaml
# FORBIDDEN — required secret with silent fallback
environment:
- DB_PASSWORD=${DB_PASSWORD:-changeme}
- API_KEY=${API_KEY:-}
# REQUIRED — fast-fail on missing required values
environment:
- DB_PASSWORD=${DB_PASSWORD:?DB_PASSWORD is required}
- API_KEY=${API_KEY:?API_KEY is required}
# ALLOWED — true convenience default, tagged
environment:
- PORT=${PORT:-3000} # safe-default: non-secret, app works at any port
```
This applies to: `docker-compose.yml`, k8s manifests, Helm `values.yaml`, any env file committed to git.
### 2. Vault KV calls in application source code (ESO-default projects)
```python
# FORBIDDEN in ESO-default apps — direct Vault client in app source
import hvac
client = hvac.Client(url=os.environ['VAULT_ADDR'])
secret = client.secrets.kv.v2.read_secret_version(path='myapp/db')
```
ESO-default apps read env vars only. Direct-Vault clients belong only in apps with a documented dynamic-secrets justification in README.
### 3. Hardcoded secrets or API keys in committed files
```python
# FORBIDDEN — hardcoded credential
DB_PASSWORD = "supersecret123"
API_KEY = "sk-live-abc123"
```
No exceptions. CI lint must flag any string matching common secret patterns (`password`, `secret`, `api_key`, `token` assigned a literal non-env-var value).
### 4. `.env` files in production deployment paths
```
# FORBIDDEN — .env file in a production deploy path
deploy/.env
k8s/.env
docker/.env
# ALLOWED — local dev only
.env.example # template only, no real values
.env # local dev, must be in .gitignore
```
`.env` files are acceptable in local-dev contexts only and MUST be in `.gitignore`. They are forbidden in any path that a CI pipeline or production deployment process reads directly.

View File

@@ -2,10 +2,9 @@
# pr-merge.sh - Merge pull requests on Gitea or GitHub
# Usage: pr-merge.sh -n PR_NUMBER [-m squash] [-d] [--skip-queue-guard]
set -euo pipefail
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# shellcheck source=packages/mosaic/framework/tools/git/detect-platform.sh
source "$SCRIPT_DIR/detect-platform.sh"
# Default values
@@ -70,11 +69,6 @@ if [[ -z "$PR_NUMBER" ]]; then
usage
fi
if [[ ! "$PR_NUMBER" =~ ^[0-9]+$ ]]; then
echo "Error: Invalid PR number '$PR_NUMBER'. PR number must contain digits only." >&2
exit 1
fi
if [[ "$MERGE_METHOD" != "squash" ]]; then
echo "Error: Mosaic policy enforces squash merge only. Received '$MERGE_METHOD'." >&2
exit 1
@@ -98,138 +92,21 @@ PLATFORM=$(detect_platform)
OWNER=$(get_repo_owner)
REPO=$(get_repo_name)
find_tea_login_for_host() {
local host="$1"
local logins_json
command -v tea >/dev/null 2>&1 || return 1
logins_json=$(tea login list --output json 2>/dev/null) || return 1
TEA_LOGINS_JSON="$logins_json" python3 - "$host" <<'PY'
import json
import os
import sys
host = sys.argv[1]
try:
logins = json.loads(os.environ.get("TEA_LOGINS_JSON", "[]"))
except Exception:
raise SystemExit(1)
for login in logins if isinstance(logins, list) else []:
url = str(login.get("url") or login.get("URL") or "")
name = str(login.get("name") or login.get("Name") or "")
if url.rstrip("/").endswith(host) and name:
print(name)
raise SystemExit(0)
raise SystemExit(1)
PY
}
is_known_tea_empty_identity_failure() {
local error_file="$1"
python3 - "$error_file" <<'PY'
import re
import sys
with open(sys.argv[1], encoding="utf-8", errors="replace") as handle:
error = handle.read()
known_empty_identity = re.search(
r"user does not exist.*\[.*uid:\s*0,\s*name:\s*\]",
error,
flags=re.IGNORECASE | re.DOTALL,
)
raise SystemExit(0 if known_empty_identity else 1)
PY
}
merge_gitea_with_api() {
local host="$1"
local api_url="https://${host}/api/v1/repos/${OWNER}/${REPO}/pulls/${PR_NUMBER}/merge"
local token body_file payload
token=$(get_gitea_token "$host" || true)
if [[ -z "$token" ]]; then
echo "Error: No Gitea API token available for authenticated merge fallback on $host." >&2
return 1
fi
mkdir -p "${AGENT_WORK_ROOT:-/home/hermes/agent-work}"
body_file=$(mktemp "${AGENT_WORK_ROOT:-/home/hermes/agent-work}/pr-merge-api-response.XXXXXX")
payload='{"Do":"squash"}'
if curl -fsS \
-X POST \
-H "Authorization: token $token" \
-H 'Content-Type: application/json' \
-d "$payload" \
"$api_url" > "$body_file"; then
rm -f "$body_file"
return 0
fi
python3 - "$body_file" <<'PY' >&2
import json
import sys
path = sys.argv[1]
try:
with open(path, encoding="utf-8", errors="replace") as handle:
raw = handle.read(500)
data = json.loads(raw) if raw else {}
message = data.get("message") or data.get("error") or raw or "empty response"
except Exception:
try:
with open(path, encoding="utf-8", errors="replace") as handle:
message = handle.read(500) or "empty response"
except Exception:
message = "unreadable response"
print(f"Error: Gitea API merge fallback failed: {message}")
PY
rm -f "$body_file"
return 1
}
case "$PLATFORM" in
github)
cmd=(gh pr merge "$PR_NUMBER" --squash)
[[ "$DELETE_BRANCH" == true ]] && cmd+=(--delete-branch)
"${cmd[@]}"
CMD="gh pr merge $PR_NUMBER --squash"
[[ "$DELETE_BRANCH" == true ]] && CMD="$CMD --delete-branch"
eval "$CMD"
;;
gitea)
HOST=$(get_remote_host) || {
echo "Error: Cannot determine host from origin remote URL" >&2
exit 1
}
TEA_LOGIN="${GITEA_LOGIN:-$(find_tea_login_for_host "$HOST" || true)}"
CMD="tea pr merge $PR_NUMBER --style squash --repo $OWNER/$REPO --login ${GITEA_LOGIN:-mosaicstack}"
# Delete branch after merge if requested
if [[ "$DELETE_BRANCH" == true ]]; then
echo "Note: Branch deletion after merge may need to be done separately with tea" >&2
fi
if [[ -n "$TEA_LOGIN" ]]; then
mkdir -p "${AGENT_WORK_ROOT:-/home/hermes/agent-work}"
TEA_ERROR_FILE=$(mktemp "${AGENT_WORK_ROOT:-/home/hermes/agent-work}/pr-merge-tea-error.XXXXXX")
if tea pr merge "$PR_NUMBER" --style squash --repo "$OWNER/$REPO" --login "$TEA_LOGIN" 2> "$TEA_ERROR_FILE"; then
rm -f "$TEA_ERROR_FILE"
elif is_known_tea_empty_identity_failure "$TEA_ERROR_FILE"; then
cat "$TEA_ERROR_FILE" >&2
echo "Known tea empty identity failure detected; using authenticated Gitea API merge fallback." >&2
rm -f "$TEA_ERROR_FILE"
merge_gitea_with_api "$HOST"
else
cat "$TEA_ERROR_FILE" >&2
rm -f "$TEA_ERROR_FILE"
exit 1
fi
else
echo "No tea login configured for $HOST; using authenticated Gitea API merge fallback." >&2
merge_gitea_with_api "$HOST"
fi
eval "$CMD"
;;
*)
echo "Error: Could not detect git platform" >&2

View File

@@ -1,216 +0,0 @@
#!/bin/bash
# Regression harness for pr-merge.sh Gitea non-interactive tea empty identity fallback.
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
WORK_ROOT="${AGENT_WORK_ROOT:-/home/hermes/agent-work}"
SANDBOX="$WORK_ROOT/pr-merge-empty-uid-test-$$"
MOCK_BIN="$SANDBOX/bin"
REPO_DIR="$SANDBOX/repo"
LOG_FILE="$SANDBOX/mock.log"
cleanup() {
rm -rf "$SANDBOX"
}
trap cleanup EXIT
mkdir -p "$MOCK_BIN" "$REPO_DIR"
: > "$LOG_FILE"
cat > "$MOCK_BIN/tea" <<'EOF'
#!/bin/bash
set -euo pipefail
printf 'tea %q ' "$@" >> "$PR_MERGE_TEST_LOG"
printf '\n' >> "$PR_MERGE_TEST_LOG"
if [[ "$*" == *"pr merge"* ]]; then
echo 'user does not exist [uid: 0, name: ]' >&2
exit 1
fi
exit 0
EOF
chmod +x "$MOCK_BIN/tea"
cat > "$MOCK_BIN/curl" <<'EOF'
#!/bin/bash
set -euo pipefail
printf 'curl %q ' "$@" >> "$PR_MERGE_TEST_LOG"
printf '\n' >> "$PR_MERGE_TEST_LOG"
args=" $* "
if [[ "$args" == *"/api/v1/repos/mosaicstack/stack/pulls/123"* && "$args" != *"/api/v1/repos/mosaicstack/stack/pulls/123/merge"* ]]; then
cat <<'JSON'
{"number":123,"title":"mock","state":"open","user":{"login":"tester"},"head":{"ref":"feature/mock"},"base":{"ref":"main"},"labels":[],"assignees":[],"html_url":"https://git.mosaicstack.dev/mosaicstack/stack/pulls/123","mergeable":true}
JSON
exit 0
fi
if [[ "$args" == *"-X POST"* && "$args" == *"/api/v1/repos/mosaicstack/stack/pulls/123/merge"* ]]; then
cat <<'JSON'
{"merged":true,"message":"mock merge complete"}
JSON
exit 0
fi
echo "unexpected curl invocation: $*" >&2
exit 97
EOF
chmod +x "$MOCK_BIN/curl"
cd "$REPO_DIR"
git init -q
git remote add origin https://git.mosaicstack.dev/mosaicstack/stack.git
export PATH="$MOCK_BIN:$PATH"
export PR_MERGE_TEST_LOG="$LOG_FILE"
export GITEA_LOGIN="git.mosaicstack.dev"
export GITEA_TOKEN="redacted-test-token"
OUTPUT="$SANDBOX/output.log"
if ! "$SCRIPT_DIR/pr-merge.sh" -n 123 -m squash --skip-queue-guard > "$OUTPUT" 2>&1; then
echo "Expected pr-merge.sh to recover via Gitea API fallback." >&2
echo "--- output ---" >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
echo "--- mock log ---" >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
if ! grep -q '/api/v1/repos/mosaicstack/stack/pulls/123/merge' "$LOG_FILE"; then
echo "Expected authenticated Gitea merge API endpoint to be called." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
if grep -q 'redacted-test-token' "$OUTPUT"; then
echo "Token leaked to pr-merge.sh output." >&2
exit 1
fi
cat > "$MOCK_BIN/tea" <<'EOF'
#!/bin/bash
set -euo pipefail
printf 'tea %q ' "$@" >> "$PR_MERGE_TEST_LOG"
printf '\n' >> "$PR_MERGE_TEST_LOG"
if [[ "$*" == *"pr merge"* ]]; then
echo 'tea network timeout' >&2
exit 2
fi
exit 0
EOF
chmod +x "$MOCK_BIN/tea"
: > "$LOG_FILE"
if "$SCRIPT_DIR/pr-merge.sh" -n 123 -m squash --skip-queue-guard > "$OUTPUT" 2>&1; then
echo "Expected arbitrary tea failure to remain blocking." >&2
exit 1
fi
if grep -q '/api/v1/repos/mosaicstack/stack/pulls/123/merge' "$LOG_FILE"; then
echo "Arbitrary tea failure unexpectedly used Gitea API merge fallback." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
if ! grep -q 'tea network timeout' "$OUTPUT"; then
echo "Expected arbitrary tea error to be preserved in output." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
exit 1
fi
cat > "$MOCK_BIN/tea" <<'EOF'
#!/bin/bash
set -euo pipefail
printf 'tea %q ' "$@" >> "$PR_MERGE_TEST_LOG"
printf '\n' >> "$PR_MERGE_TEST_LOG"
if [[ "$*" == *"login list"* ]]; then
echo '[]'
exit 0
fi
if [[ "$*" == *"pr merge"* ]]; then
echo 'tea merge should not run without a configured host login' >&2
exit 99
fi
exit 0
EOF
chmod +x "$MOCK_BIN/tea"
unset GITEA_LOGIN
: > "$LOG_FILE"
if ! "$SCRIPT_DIR/pr-merge.sh" -n 123 -m squash --skip-queue-guard > "$OUTPUT" 2>&1; then
echo "Expected missing tea login to use authenticated Gitea API fallback." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
if ! grep -q '/api/v1/repos/mosaicstack/stack/pulls/123/merge' "$LOG_FILE"; then
echo "Expected missing tea login path to call Gitea API merge endpoint." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
SENTINEL="$SANDBOX/injected-sentinel"
INJECTION="123; touch $SENTINEL #"
cat > "$MOCK_BIN/gh" <<'EOF'
#!/bin/bash
set -euo pipefail
printf 'gh %q ' "$@" >> "$PR_MERGE_TEST_LOG"
printf '\n' >> "$PR_MERGE_TEST_LOG"
if [[ "$*" == *"pr view"* ]]; then
cat <<'JSON'
{"number":123,"title":"mock","baseRefName":"main","headRefName":"feature/mock"}
JSON
exit 0
fi
if [[ "$*" == *"pr merge"* ]]; then
exit 0
fi
echo "unexpected gh invocation: $*" >&2
exit 98
EOF
chmod +x "$MOCK_BIN/gh"
cd "$REPO_DIR"
git remote set-url origin https://github.com/mosaicstack/stack.git
: > "$LOG_FILE"
rm -f "$SENTINEL"
if "$SCRIPT_DIR/pr-merge.sh" -n "$INJECTION" -m squash --skip-queue-guard > "$OUTPUT" 2>&1; then
echo "Expected GitHub metacharacter PR number to be rejected." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
exit 1
fi
if [[ -e "$SENTINEL" ]]; then
echo "GitHub metacharacter PR number executed injected shell command." >&2
exit 1
fi
if [[ -s "$LOG_FILE" ]]; then
echo "GitHub metacharacter PR number should be rejected before gh calls." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
if ! grep -q 'Invalid PR number' "$OUTPUT"; then
echo "Expected invalid PR number error for GitHub metacharacter input." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
exit 1
fi
cd "$REPO_DIR"
git remote set-url origin https://git.mosaicstack.dev/mosaicstack/stack.git
export GITEA_LOGIN="git.mosaicstack.dev"
: > "$LOG_FILE"
rm -f "$SENTINEL"
if "$SCRIPT_DIR/pr-merge.sh" -n "$INJECTION" -m squash --skip-queue-guard > "$OUTPUT" 2>&1; then
echo "Expected Gitea metacharacter PR number to be rejected." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
exit 1
fi
if [[ -e "$SENTINEL" ]]; then
echo "Gitea metacharacter PR number executed injected shell command." >&2
exit 1
fi
if [[ -s "$LOG_FILE" ]]; then
echo "Gitea metacharacter PR number should be rejected before tea/curl calls." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$LOG_FILE" >&2
exit 1
fi
if ! grep -q 'Invalid PR number' "$OUTPUT"; then
echo "Expected invalid PR number error for Gitea metacharacter input." >&2
sed 's/redacted-test-token/***REDACTED***/g' "$OUTPUT" >&2
exit 1
fi
echo "pr-merge.sh Gitea fallback regression passed"