sneak/pixa
1
0
Fork 0
Code Issues 55 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Docker image bakes the example config with a placeholder signing key; take the key from the environment and refuse the placeholder #110

New Issue
Open
opened 2026-09-21 09:19:48 +02:00 by clawbot · 1 comment
clawbot commented 2026-09-21 09:19:48 +02:00
Collaborator
Copy Link
Copy Source

Verified against next at 2d80512.

Dockerfile copies config.example.yml to /etc/pixa/config.yml and the ENTRYPOINT loads it. That file's signing_key is the placeholder CHANGE_ME_generate_with_openssl_rand_base64_32, which is 45 characters long and therefore passes the startup check (signing_key must be at least 32 characters). Result: a container started from the image with no override runs, and accepts image URLs signed with a key that is public in this repository. It also bakes a five-host allowlist_hosts list into every deployment.

upaas (the target for the 2026-09-30 beta on fsn1app1) configures an app with environment variables and volume mounts; it injects no config file.

The config loader already supports ${ENV:NAME} interpolation (smartconfig), and an unset variable referenced that way aborts startup naming the variable. That is the right behavior for a secret.

Definition of done

  1. The image ships a config file (config.docker.yml, or a better name) instead of config.example.yml, containing only: signing_key: ${ENV:PIXA_SIGNING_KEY}, state_dir: /var/lib/pixa, and port: 8080. No allowlist, no placeholder secret. Every other key is omitted so its default applies; operators who need more mount a file over /etc/pixa/config.yml.
  2. A container started without PIXA_SIGNING_KEY exits non-zero with an error that names PIXA_SIGNING_KEY. A container started with a 32+ character value serves /.well-known/healthcheck.json. Verify both by running the built image; state in the PR body that you did, not the transcript.
  3. config.example.yml stays as the documented example for file-based setups but its placeholder must be rejected: startup refuses that exact placeholder string with an error naming signing_key. Failing test first.
  4. README.md documents the two ways to configure a container (env var for the key, mounted file for everything else) in a short paragraph under Getting Started; no separate deployment guide here (that is #89).
  5. make check green.

Constraints

  • Dockerfile is also touched by #104 and #101 (check stages). This issue changes only the runtime stage; rebase onto current next before pushing.
  • PORT as an environment override of the listen port is #99, not this issue.
  • No 4-byte characters, no scripted edits, hash-pinned images only.

model: claude-fable-5

Verified against `next` at `2d80512`. `Dockerfile` copies `config.example.yml` to `/etc/pixa/config.yml` and the `ENTRYPOINT` loads it. That file's `signing_key` is the placeholder `CHANGE_ME_generate_with_openssl_rand_base64_32`, which is 45 characters long and therefore passes the startup check (`signing_key` must be at least 32 characters). Result: a container started from the image with no override runs, and accepts image URLs signed with a key that is public in this repository. It also bakes a five-host `allowlist_hosts` list into every deployment. upaas (the target for the 2026-09-30 beta on `fsn1app1`) configures an app with environment variables and volume mounts; it injects no config file. The config loader already supports `${ENV:NAME}` interpolation (smartconfig), and an unset variable referenced that way aborts startup naming the variable. That is the right behavior for a secret. ## Definition of done 1. The image ships a config file (`config.docker.yml`, or a better name) instead of `config.example.yml`, containing only: `signing_key: ${ENV:PIXA_SIGNING_KEY}`, `state_dir: /var/lib/pixa`, and `port: 8080`. No allowlist, no placeholder secret. Every other key is omitted so its default applies; operators who need more mount a file over `/etc/pixa/config.yml`. 2. A container started without `PIXA_SIGNING_KEY` exits non-zero with an error that names `PIXA_SIGNING_KEY`. A container started with a 32+ character value serves `/.well-known/healthcheck.json`. Verify both by running the built image; state in the PR body that you did, not the transcript. 3. `config.example.yml` stays as the documented example for file-based setups but its placeholder must be rejected: startup refuses that exact placeholder string with an error naming `signing_key`. Failing test first. 4. `README.md` documents the two ways to configure a container (env var for the key, mounted file for everything else) in a short paragraph under Getting Started; no separate deployment guide here (that is https://git.eeqj.de/sneak/pixa/issues/89). 5. `make check` green. ## Constraints - `Dockerfile` is also touched by https://git.eeqj.de/sneak/pixa/issues/104 and https://git.eeqj.de/sneak/pixa/issues/101 (check stages). This issue changes only the runtime stage; rebase onto current `next` before pushing. - `PORT` as an environment override of the listen port is https://git.eeqj.de/sneak/pixa/issues/99, not this issue. - No 4-byte characters, no scripted edits, hash-pinned images only. model: claude-fable-5
clawbot added this to the 1.0.0 milestone 2026-09-21 09:19:48 +02:00
clawbot commented 2026-09-21 09:26:26 +02:00
Author
Collaborator
Copy Link
Copy Source

Plan:

  1. Add config.docker.yml (root, beside config.example.yml): only signing_key: "${ENV:PIXA_SIGNING_KEY}", state_dir: /var/lib/pixa, port: 8080. smartconfig aborts naming PIXA_SIGNING_KEY when it is unset.
  2. Dockerfile runtime stage: COPY config.docker.yml instead of config.example.yml. Only the runtime stage is touched.
  3. Reject the exact config.example.yml placeholder at startup with an error naming signing_key (it is 45 chars and currently passes the length check). Failing test first, then the fix in internal/config.
  4. README.md Getting Started: short paragraph on the two container-config paths (env var for the key; mounted file for everything else).
  5. Verify by running the built image: no PIXA_SIGNING_KEY exits non-zero naming it; a 32+ char value serves the healthcheck.

model: claude-opus-4-8

Plan: 1. Add `config.docker.yml` (root, beside `config.example.yml`): only `signing_key: "${ENV:PIXA_SIGNING_KEY}"`, `state_dir: /var/lib/pixa`, `port: 8080`. smartconfig aborts naming `PIXA_SIGNING_KEY` when it is unset. 2. `Dockerfile` runtime stage: `COPY config.docker.yml` instead of `config.example.yml`. Only the runtime stage is touched. 3. Reject the exact `config.example.yml` placeholder at startup with an error naming `signing_key` (it is 45 chars and currently passes the length check). Failing test first, then the fix in `internal/config`. 4. `README.md` Getting Started: short paragraph on the two container-config paths (env var for the key; mounted file for everything else). 5. Verify by running the built image: no `PIXA_SIGNING_KEY` exits non-zero naming it; a 32+ char value serves the healthcheck. model: claude-opus-4-8
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
merge-ready
needs-checks
needs-rebase
needs-review
needs-rework
No labels
Milestone
No items
No Milestone 1.0.0
Projects
Clear projects
No projects
Assignees
Clear assignees
clawbot sneak (Jeffrey Paul)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/pixa#110