Files
dtf-system/local/static/vendor
Cauê Faleiros da903db32a
All checks were successful
Build and deploy / Validate source (push) Successful in 5s
Build and deploy / Integration suite on a real stack (push) Successful in 1m10s
Build and deploy / Secret scan and release gate (push) Successful in 5s
Build and deploy / Publish images and notify Portainer (push) Successful in 1m43s
feat: serve pdf.js from this origin instead of a CDN
The Site pulled pdf.js 3.11.174 from cdnjs with no integrity attribute, and the
policy trusted the whole of cdnjs.cloudflare.com for both script-src and
worker-src. Anything that host served would have executed, and a customer
measuring a PDF sheet depended on it being reachable.

Vendor both files instead of pinning a hash: it removes the dependency rather
than constraining it, and lets the policy name only 'self'. Provenance and
SHA-256 digests are recorded in local/static/vendor/README.md, verified on
download against the SRI digests cdnjs publishes for that release.

cdnjs is now absent from script-src, worker-src and connect-src in both gateway
templates. Workers are 'self' plus blob:, which the Site needs for the worker it
constructs itself.

Verified in a browser against the running stack: pdf.js loads from /vendor/, the
blob worker starts, and a real seven-page PDF parses with no CSP violation. Both
browser suites and the full integration suite pass.

The version is deliberately unchanged. 3.11.174 is old, but its known eval path
is already closed by isEvalSupported:false, and upgrading is an API change that
needs its own testing rather than riding along with this.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-21 13:56:02 -03:00
..

Vendored third-party assets

Served from this repository rather than a CDN, so the Site does not depend on a third party being reachable and honest at the moment a customer opens it, and so the Content-Security-Policy can name only 'self' for scripts and workers.

pdf.js 3.11.174

Used by the by-metre flow to measure and rasterise a PDF sheet in the browser.

File SHA-256
pdf.min.js 5b5799e6f8c680663207ac5b42ee14eed2a406fa7af48f50c154f0c0b1566946
pdf.worker.min.js feabdf309770ed24bba31a5467836cdc8cf639c705af27d52b585b041bb8527b

Downloaded from https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/ and verified against the SRI digests cdnjs publishes for that release:

pdf.min.js         sha512-q+4liFwdPC/bNdhUpZx6aXDx/h77yEQtn4I1slHydcbZK34nLaR3cAeYSJshoxIOq3mjEf7xJE8YWIUHMn+oCQ==
pdf.worker.min.js  sha512-BbrZ76UNZq5BhH7LL7pn9A4TKQpQeNCHOo65/akfelcIBbcVvYWOFQKPXIrykE3qZxYjmDX573oa4Ywsc7rpTw==

To verify or refresh, compare against that API before replacing anything:

curl -s "https://api.cdnjs.com/libraries/pdf.js/<version>?fields=sri"

Version note. 3.11.174 is old. It is affected by GHSA-wgrm-67xf-hhpq, whose documented workaround is isEvalSupported: false; dtf-site.html already passes that, so the known path is closed. Upgrading is worthwhile but is an API change, not a file swap, and belongs with its own browser testing — see ROADMAP.md 2.7.