PDF.js's signature dialog saved every signature in the PDF origin's
localStorage, "save" ticked on every open, so the next person on a
shared device was offered the previous one's, a bau-pm logout
included. The glue now wipes that store, refuses its writes, holds the
save box off and hides it, and hides the dialog's Bild tab (#1, bau-pm
BAU-260, PLAN.md §2.77 there).
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, nginx
1.31.8; the zero-hosts gate drove all 117 tool pages and nothing left
the origin; the new signatures gate: 0 findings (9 on v0.1.0).
bau-pm pins this as v0.28.1.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PDF.js's signature dialog saved every signature in localStorage under
pdfjs.signature, "save" ticked on every open, for this origin rather
than for a bau-pm user. Measured on v0.1.0: a typed and an uploaded
signature were offered to a fresh page on the same browser, the way the
next person on a shared tablet would get it, a Redmine logout included.
Another browser profile saw nothing; the server never had anything.
The glue's fifth duty, in every window before PDF.js's modules: delete
the store (a device that saved signatures loses them on its first
visit), refuse writes to that key, hold the save box unticked through a
property on the element and hide it, and hide the dialog's Bild tab and
its file picker, so a scanned signature never enters the dialog.
test/signatures.mjs is the second gate, in CI and the release workflow:
a browser seeded with a real saved entry (captured from v0.1.0's own
store) is offered none, the dialog shows neither the box nor the tab, a
typed signature is placed and not stored, a fresh page is offered
nothing. Fed v0.1.0: 9 findings, exit 1. Against this image: 0, and the
zero-host gate drove 117 tool pages with nothing leaving the origin. A
signed PDF still exports with the signature on the page.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Finding 41 of bau-pm's v0.22.3 security review called this a pin to move.
It is not a pin: both bases here are floating tags, so what ships is
whatever the runner had cached. v0.1.0 went out with nginx 1.31.6 while
quay.io/nginx/nginx-unprivileged:alpine-slim had already moved to 1.31.8,
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.
The CI build gets it too: a gate running against a months-old cached base
is not testing what the release builds.
A release is what applies this. The running image does not change until one
is cut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The image and the gate as in 47138dd: the zero-host gate green on all 117
enabled tool pages (CI form, private network, 3 min 52 s), red on the stock
image (115 findings) and on a misspelled disabled id.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
BentoPDF v2.8.8 built from source at its pinned commit with BentoPDF's own
air-gapped build options, every module it would load from a CDN vendored and
checked against vendor.lock, a Content-Security-Policy without a single host,
digital-sign-pdf and timestamp-pdf disabled because both need a third party,
and the hand-off glue on every page: the AGPL source link, the hand-in of a
file from bau-pm through a one-minute cookie into sessionStorage, confirmed by
the tool's reaction, the hand-back of a result from every window, and the
signing tool's flatten switch locked on.
The zero-host gate drives all 117 enabled tool pages in Chromium and fails on
any request to another origin, any CSP violation, a CSP that names a host, and
a disabled id that names no page. Green on this image (3 min 52 s on a private
network), red on the stock upstream image (115 findings) and on a misspelled
id. CI runs it on every push, the release workflow before it pushes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
magdevandClaude Opus 5.5