0005_verification_decisions landed in DEV-612 but validate.yml still
assumed four migrations: it ran migrate down 3 (leaving
verification_decisions in place) and never grep'd for it on the up-pass.
Bump the roll-back to 4 and add the table to both the up-verify and
down-absent lists so the DB job matches reality again.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Add the Phase-1 end-to-end smoke test harness required by the parent
plan ([DEV-606](/DEV/issues/DEV-606), subtask 7/10):
- `tools/webauthn-sign/`: tiny Go CLI for the two crypto operations
shell + openssl cannot do (`gen-key` → Ed25519 keypair; `sign-assertion`
→ WebAuthn PublicKey assertion over the server-supplied challenge).
- `scripts/phase1-smoke.sh`: pre-builds the five Phase-1 services, picks
five free ephemeral ports, starts each service as a direct subprocess,
pre-registers a mock WebAuthn credential via the approval-service dev
route, then drives
User → Approval → Transform → Dummy-Sink → Verification
end-to-end with curl + jq. Asserts:
* the sink wrote `<data>/<decision_id>.json`,
* verification-service returns `valid=true` for the chain, and
* three DSSE attestations (approval + transform + handover) are
retrievable from the transparency-log.
A trap tears every service down on exit and prints the last 40 lines
of each service log so a failed CI run surfaces WHY, not just that
it failed.
- `Makefile`: minimal, exposes `make phase1-smoke` at repo root.
- `.forgejo/workflows/phase1-smoke.yml`: runs the same harness in a
`golang:1.26-alpine3.23` container, following the sha256-clone pattern
from `validate.yml`. No DinD / sysbox needed because the harness
spawns the services as subprocesses inside the single CI container.
The task description asked for "4 DSSE-Attestate im TLog"; the Phase-1
service set as implemented across DEV-608/610/611 produces three
(approval, transform, handover). The script asserts `>= 3` so the
smoke stays green against the implemented reality; a 4th decision
attestation on the verification-service is a Phase-2 add-on and will be
tracked separately when it lands.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
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 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>
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>
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>
- 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>
