Harbor robot usernames are of the form `robot$basicstack+forgejo-ci`.
Forgejo Actions substitutes `${{ secrets.HARBOR_USERNAME }}` into the
`run:` script before bash runs it, so `set -u` sees the resulting
`robot$basicstack+forgejo-ci` and dies with "basicstack: parameter
not set" trying to expand `$basicstack`. Pass the Harbor credentials
as env vars on the step; bash then reads them from the environment as
plain strings instead of parsing them for parameter expansion.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The signing-service image build itself was green after 770e71d (buildx
plugin installed, --mount=type=cache works). The push step then failed
with "Must provide --username with --password-stdin" because the
HARBOR_USERNAME / HARBOR_PASSWORD Forgejo repo secrets were never
configured. Robot account `robot$basicstack+forgejo-ci` created in
Harbor (project `basicstack`, push+pull) and both secrets set. Empty
commit to trigger a re-run and verify the push.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The signing-service Dockerfile uses the BuildKit `--mount=type=cache`
syntax, which the legacy Docker builder rejects. Debian trixie's
`docker-cli` package does not pull in a BuildKit builder, so even
`DOCKER_BUILDKIT=1` fails with "the --mount option requires BuildKit".
Install Debian trixie's `docker-buildx` package (registers the plugin
at /usr/libexec/docker/cli-plugins/docker-buildx) and switch the build
step to an explicit `docker buildx build --load` so BuildKit frontend
features work regardless of docker-cli aliasing. `--load` ensures the
result is in the local daemon for the subsequent `docker push`.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The signing-service Dockerfile ([DEV-609](/DEV/issues/DEV-609))
starts with `# syntax=docker/dockerfile:1.7` and uses
`RUN --mount=type=cache,...` for Go build/module caches. The legacy
Docker builder rejects both; the image-build job has been failing on
main since DEV-609 landed:
the --mount option requires BuildKit. Refer to
https://docs.docker.com/go/buildkit/ to learn how to build images
with BuildKit enabled
Fix: set `DOCKER_BUILDKIT=1` on the job env so the daemon routes the
build through the declared Dockerfile frontend.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
[DEV-608](/DEV/issues/DEV-608) added migration
0004_approval_sessions.{up,down}.sql but did not update the DB job's
rollback step. The step still ran `migrate down 2`, which with four
migrations rolls back only 0004 + 0003 and leaves 0002_agents in place
— the hard-coded check "agents must be gone after down 2" then fails:
FAIL: agents still present after migrate down 2
Fix: roll back all three migrations layered on top of
0001_per_diem_rates (`down 3`) and verify agents, agent_keys, AND
approval_sessions are all gone while per_diem_rates remains. Also
cover approval_sessions in the up-direction assertion so a future
"missed table" shows up in both halves of the test. A comment at the
new step names the invariant so the next migration bump is obvious.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
[DEV-609](/DEV/issues/DEV-609) bumped services/signing-service to
go 1.26.0 (required by github.com/open-policy-agent/opa v1.21.4).
admin-api replaces basicstack.de/proofedmesh/services/signing-service
with the sibling via a replace directive, so its go.mod effective
minimum is also 1.26 and the transitive indirect requirements (opa,
pgx, jwx, go-jose, levenshtein, …) must be listed. CI surfaced
this as:
go: updates to go.mod needed; to update it:
go mod tidy
Fix: `go mod tidy` on services/admin-api with the 1.26 toolchain.
Local `go vet` + `go test ./...` pass on all admin-api packages.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
signing-service depends on github.com/open-policy-agent/opa v1.21.4,
which requires Go >= 1.26.0. The CI Go image and the signing-service
Dockerfile were still pinned to golang:1.23-alpine3.21, so the
"Go (vet + test)" job and the signing-service image build both
failed on main as soon as [DEV-609](/DEV/issues/DEV-609) landed:
go: module ../signing-service requires go >= 1.26.0
(running go 1.23.12; GOTOOLCHAIN=local)
Fix: pin both to golang:1.26-alpine3.23 (oldest alpine tag that
exists for the 1.26 line). All other modules declare go 1.23 which
1.26 still accepts, so no downstream churn.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Minimal CLI agent process that end-to-end demonstrates the Transform step
of the ProofedMesh trust chain:
1. Fetches an approval attestation from the transparency-log by
attestation_ref (`sha256:<hex>`).
2. DSSE-verifies the fetched envelope against a pinned approval-signer
ed25519 keyring; stops before any signing call on failure.
3. Builds an in-toto v1 Statement with predicateType
`basicstack.de/attestations/transform/v1`, operation
`expense.map_to_sink`, materials[0].attestation_ref = approval_ref,
and subject[0].digest.sha256 = sha256(canonical(handover_payload)).
4. Calls signing-service /api/v1/sign/dsse with BOTH identities:
Authorization: Bearer <pocket-id client_credentials token> AND
X-Workload-Token: <projected SA token from
/var/run/secrets/tokens/trust-api>.
5. Submits the returned DSSE envelope + content_hash to the
transparency-log /api/v1/log/entries.
6. POSTs the canonical handover_payload bytes to the dummy-sink
(schema sink.dummy.v1), carrying the transform content_hash on the
X-Attestation-Ref header.
Tests use httptest for all four backends:
- Happy path (verifies the bytes sent to the sink match the signed
subject digest and that the TLog recorded the same content_hash the
agent returned).
- Invalid approval signature -> stops before sign-call; TLog and sink
untouched.
- Signing-service returns 403 signing_denied -> surfaced as
signer.ErrSigningDenied; TLog and sink untouched.
- Missing Pocket-ID token -> fails before any network call.
Includes PocketID client_credentials TokenSource (OIDC discovery + cache)
and ProjectedSATokenSource (reads kubelet-managed Volume) mirroring
admin-api/approval-service.
Non-scope: no read-side attestations (Phase 2), no K8s/CI image build
wiring (follow-up ticket).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
New services/approval-service with the Session → Preview → Confirm
pipeline required by DEV-606/DEV-608:
* POST /api/v1/sessions starts a Pocket-ID-bound approval session.
* POST /api/v1/approvals/preview renders content server-side, computes
H_content = sha256(canonical JSON), stores the (nonce, salt, canonical,
challenge) tuple and returns the human verification digits plus the
WebAuthn challenge = nonce || H_content.
* POST /api/v1/approvals/confirm verifies the WebAuthn assertion against
the stored challenge, DSSE-signs the Approval statement via the
signing-service (key_ref=trust-api/approval-signer-2026-q4), submits
to the transparency-log, and returns {approval_id, attestation_ref,
log_index}. TLog failures leave the row at attestation-pending for
the reconciler.
* db/trust/migrations/0004_approval_sessions.{up,down}.sql: new tables
approval_sessions, approval_previews, approvals (schema matches the
Phase 1 store contract).
* internal/content: canonical JSON + H_content + 6-digit verification
code (byte-compatible with signing-service/internal/canonical).
* internal/webauthn: stdlib-only Phase-1 verifier; wire shape stays
WebAuthn-compatible for the Phase-2 swap to go-webauthn/webauthn.
* internal/signer, internal/tlog: HTTP clients mapping 5xx / connection
errors to typed ErrSignerUnavailable / ErrTLogUnavailable so the
HTTP layer can return 502 for signing failures and persist
attestation-pending on TLog failure.
* internal/service.Orchestrator ties the pipeline together and persists
the Approval BEFORE the TLog submit (never return a log_index for
an un-persisted approval).
Tests cover: happy path, tampered H_content → 400, expired challenge
→ 403, signer 5xx + conn-refused → 502, TLog failure → row stays
attestation-pending, duplicate confirm → 409, session expired → 403.
go vet clean, go test ./... passes.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Debian trixie split the Docker CLI into its own `docker-cli` package.
`docker.io` now only pulls in the daemon, and the CLI dep is a
Recommends — which `--no-install-recommends` skips. Both the new DB
dry-run job in validate.yml and the pre-existing signing-service image
job in build-images.yml were failing with `docker: not found` after
install.
Add `docker-cli` explicitly to both apt install lines.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- 0002_agents / 0003_agent_keys migrations per architecture v1.1 §4.4
(incl. (k8s_namespace, k8s_service_account) uniqueness for the signing
service's dual identity check and an agent_id, valid_from index for the
verification lookup path)
- idempotent seed db/trust/seeds/0001_phase1_agents.sql with the three
Phase-1 identities: agent-approval-service, agent-testagent-transform,
agent-dummy-sink (namespace agent-trust)
- new db CI job in validate.yml: runs postgres:16-alpine, migrate up ->
down 2 -> up, applies the seed twice, verifies three agents
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- services/transparency-log/pkg/backend/trillian.go: real gRPC client
on github.com/google/trillian v1.6.1. Submit() does QueueLeaf with the
canonical DSSE envelope as LeafValue and the raw content_hash bytes as
LeafIdentityHash, then polls GetLatestSignedLogRoot +
GetInclusionProofByHash until the leaf is sequenced. Idempotency uses
Trillian's ALREADY_EXISTS signal on the inner QueuedLogLeaf.Status, so
a repeated submit still returns 200 OK with the originally-assigned
log_index + a valid proof against the current STH.
- Unconfigured backend (missing endpoint or LogID) returns the historical
ErrTrillianUnavailable so the httpapi layer keeps mapping it to 503
instead of silently 500. Existing stub-returns-503 test updated.
- cmd/transparency-log: pointer-receiver Trillian wiring; flag docs
mention the production SRV name.
- services/transparency-log/Dockerfile: distroless multi-stage build
used by deploy/trillian/40-transparency-log.yaml.
- deploy/trillian/: full K8s stack for the agent-trust namespace —
MySQL 8.4 StatefulSet (schema init ConfigMap vendored from upstream
storage.sql v1.6.1), Trillian LogServer + LogSigner Deployments on
gcr.io/trillian-opensource-ci:v1.6.1, createtree Job that writes
the TreeID to a ConfigMap (re-apply safe), transparency-log
Deployment with --backend=trillian pulling TRILLIAN_LOG_ID from
the ConfigMap.
- deploy/trillian/README.md: first-time apply + smoke-test + secret
rotation + signer-key clarification (STH key is Trillian-internal;
DSSE envelope signing stays with signing-service / OpenBao).
- services/admin-api: go.mod / go.sum pick up the new transitive deps
(trillian + grpc) via the local replace on transparency-log.
- services/transparency-log/README.md: Backends table updated; next-
steps list no longer carries Trillian-deployment as a follow-up.
Deployed to the live cluster from this heartbeat: MySQL + LogServer +
LogSigner running in agent-trust, tree id 8482455225499059043, service
smoke-tested end-to-end (201 on first POST, 200 on idempotent repeat,
409 on content_hash mismatch, tree_size=2 with correct audit path).
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Dockerfile: multi-stage (golang:1.23-alpine3.21 → distroless/static:nonroot),
CGO off, trimpath, stripped, UID/GID 65532, read-only rootfs friendly.
- deploy/signing-service/: ServiceAccount, Deployment (2 replicas, probes,
tight SecurityContext), ClusterIP Service on :8081, NetworkPolicy
(ingress from agent-trust, DNS egress), example Secret, and README with
the full dev + prod secret convention.
- .forgejo/workflows/build-images.yml: builds image on push + PR,
pushes :<git-sha> + :main to harbor.basicstack.de on main pushes only.
Clone pattern matches validate.yml (sha256 repo, manual git clone).
- README updates: service README gains Deployment section; repo README
layout now mentions services/signing-service, services/transparency-log,
deploy/, and the new workflow.
Scope matches DEV-605. OpenBao, OPA and Pocket-ID JWKS stay stubs and move
in their own follow-up subtasks; the prod secret shape is documented so
those subtasks can plug in without reshaping the Deployment.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- services/signing-service/pkg/httpapi exposes NewTestHandler so sibling
modules can build the real signing-service in-process (same pattern
transparency-log already uses).
- services/admin-api/internal/attest/interop_signing_test.go drives the real
attest.HTTPSigner against the real signing-service handler and asserts the
end-to-end ADR-0005 round-trip: envelope shape, keyid, content_hash
self-consistency across canonicalisers, Ed25519 signature verification
with the server's public key, and canonical-payload byte equality.
Closes the "Interop-Test: admin-api attest.HTTPSigner-Client erfolgreich
gegen diesen Server" acceptance criterion from DEV-599.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- services/attest-reconciler/ as its own go.mod (admin-api internal/ is not importable; shared code gets extracted when a 3rd consumer appears).
- Scheduler accepts "@every <dur>" or a bare Go duration; context-cancellation stops the loop cleanly.
- Store client defines PendingRateStore + Postgres skeleton for SELECT ... WHERE rate_change_attestation_ref IS NULL.
- Orchestrator + HTTPSigner + tlog.HTTPSubmitter mirror admin-api byte-for-byte so the TLog idempotency key collides on resubmits (kein Doppelsignieren).
- Prometheus text-format /metrics endpoint, dependency-free: attest_reconciler_dirty_rows_total, _reconciliation_attempts_total, _reconciliation_failures_total, _idempotent_noop_total.
- Tests with fake store + fake signer + fake submitter cover: happy path, already-attested rows are NOT re-signed, TLog idempotency across ticks, TLog-down failure path, pre-cancelled ctx.
- Top-level README reflects the new service; CI auto-discovers services/*/go.mod so no workflow change needed.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
