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>

.gitea/workflows/ci.yml

@@ -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

.gitea/workflows/release.yml

@@ -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

CHANGELOG.md

@@ -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.