The Docker build for the worker image failed at npm ci --ignore-scripts with a\n403 from cdn.sheetjs.com. SheetJS distributes off the npm registry via their own\nCDN, and that CDN blocks datacentre IP ranges, so the tarball URL dependency can\nbe fetched from a developer machine but not from a GitHub Actions runner.
Re-pinning to the registry was not a way out. xlsx@0.18.5 is the last version\nSheetJS published to npm and carries two unpatched high-severity advisories that\nnpm audit reports as fixAvailable: false, because there is nothing newer on the\nregistry to upgrade to:
\nThe prototype pollution advisory is reachable: member-bulk-load parses a workbook\nthe user has just uploaded. So the library is replaced rather than re-pinned.
\nexceljs is npm-hosted, maintained and free of known advisories. It was the single\nconsumer in the codebase, at one call site.
\nTo show the swap is behaviour-neutral, regression tests were written against the\nexisting xlsx reader and confirmed green first, then re-run unchanged against\nexceljs. That caught four cell types which sheet_to_json silently flattens but\nexceljs returns as objects, and which a direct swap would have written into member\nrecords as [object Object]:
\nExcel auto-hyperlinks email addresses, so the first of those was a live risk on a\nreal Ramblers export. The new reader normalises all four, and a test asserts no raw\ncell object can reach a row value.
\nOne divergence cannot be removed: exceljs collapses an empty-string cell to null, so\nthe empty-string versus absent-key distinction is lost. Rather than assume that was\nharmless, the row-to-member mapping was extracted and tested directly: every field\npasses through trim(), and trim(undefined) === trim("") === "", so the member records\nare identical either way.
\nExcel date cells are still read as serial numbers, as they were before. Real Ramblers\nexports store dates as strings, so this has never been hit. Preserved bug-for-bug so a\nsecurity fix does not also change data handling.
\n"}