Release v0.1.1: the same BentoPDF on current packages

Nothing in this repository's own code changed. What changed is that a build no longer ships whatever base image the runner had cached, so this image carries nginx 1.31.8 where v0.1.0 carried 1.31.6 - past five October CVEs, none of them reachable in a static file server configured like this one, which is why --pull is the fix rather than a pin. Out of bau-pm's v0.22.3 security review, finding 41 (bau-pm BAU-191). Gate, the same one CI runs, on this tree: shellcheck clean over scripts/; the image built with --pull, BentoPDF v2.8.8 verified at its pinned commit, 2776 pages tagged with a CSP carrying no host; the zero-hosts gate drove all 117 tool pages against the running image and nothing left the origin; nginx 1.31.8 in the built image. bau-pm still pins 0.1.0 in compose.yaml and .env.example, so this reaches a running instance only once that pin moves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pull the base images fresh on every build (bau-pm BAU-191)
2026-10-24 10:18:20 +02:00 · 2026-10-24 00:36:26 +02:00
3 changed files with 22 additions and 2 deletions
@@ -28,7 +28,10 @@ jobs:
      # shared runner; the vendor stage downloads about 60 MB from npm.
      - name: build the image
        timeout-minutes: 60
-        run: docker build --build-arg VERSION="ci-${GITHUB_SHA::8}" -t bau-pm-pdf-tools:ci .
+        # --pull, as in the release workflow (bau-pm BAU-191): both bases are
+        # floating tags, and a gate that runs against a months-old cached base
+        # is not testing what the release builds.
+        run: docker build --pull --build-arg VERSION="ci-${GITHUB_SHA::8}" -t bau-pm-pdf-tools:ci .

      - name: build the gate
        timeout-minutes: 15
@@ -42,8 +42,13 @@ jobs:

      - name: build the image
        timeout-minutes: 60
+        # --pull (bau-pm BAU-191, review finding 41). Both base images are
+        # floating tags - node:20-alpine and nginx-unprivileged:alpine-slim -
+        # so the nginx and OS packages that ship are whatever the tag pointed
+        # at when the runner last pulled it. v0.1.0 went out with nginx 1.31.6
+        # while the tag had moved to 1.31.8. This is the build people run.
        run: |
-          docker build --build-arg VERSION="v$VERSION" \
+          docker build --pull --build-arg VERSION="v$VERSION" \
            -t "$REGISTRY/$IMAGE:$VERSION" -t "$REGISTRY/$IMAGE:latest" .

      - name: gate - nothing leaves the origin
@@ -4,6 +4,18 @@ All notable changes to this project are documented in this file. The format is b

 ## [Unreleased]

+## [0.1.1] - 2026-10-24
+
+The same BentoPDF on current packages. Nothing in this repository's own code changed; what changed is that a build no longer ships whatever base image the runner happened to have cached, so this image carries nginx 1.31.8 where v0.1.0 carried 1.31.6. Out of bau-pm's v0.22.3 security review.
+
+### Security
+
+- The CI and release builds pull their base images fresh (`docker build --pull`). Both bases are floating tags, so what shipped was whatever the runner had cached: v0.1.0 went out with nginx 1.31.6 while the tag had already moved to 1.31.8, past five October CVEs. None of the five is reachable in a static file server configured like this one, which is why this is the fix rather than a pin. From bau-pm's v0.22.3 security review, finding 41 (bau-pm BAU-191). **A release is what applies it** - the running image does not change until one is cut.
+
+### Changed
+
+- The image is built on the current `node:20-alpine` and `nginx-unprivileged:alpine-slim`, which is where the operating-system packages under BentoPDF come from. BentoPDF itself is unchanged: still v2.8.8 at the same pinned commit, the same vendored modules at the same integrity hashes, the same two tools disabled.
+
 ## [0.1.0] - 2026-10-10

 The first release: BentoPDF v2.8.8 for bau-pm, about 120 PDF tools that run in the browser and talk to no third party, with the hand-off that brings a PDF from bau-pm into a tool and the result back.