3 Commits

Include renames

Author	SHA1	Message	Date
dc	0d58be975d	fix(ci): restore the gitleaks ignore entries for the mock licence pair ... 116c37b removed them on the grounds that a three-segment fingerprint matches nothing. That is wrong for the mode this repo scans in: with `--no-git`, gitleaks reports a finding as `file:rule:***` - the line number is not part of the fingerprint - so the entries were matching, and the pipeline failed on the next push with two findings in sas/mocks/mock-licence.json. Measured on a clean checkout of this head, with the pinned tool (@nogoo9/gitleaks 8.30.1-post.2) and the command the workflow runs: with .gitleaksignore 6.10 MB scanned, no leaks found without it 6.10 MB scanned, leaks found: 2 The 6.10 MB scan is the same figure the CI log reports, which is what makes this comparable; my earlier check was run in a tree that still had node_modules in it, scanned 1.05 GB, and its verdict meant nothing. The entries stay, with the comment explaining that the pair is RSA key material for the browser mock rather than a credential.	2026-10-26 10:34:36 +00:00
dc	116c37b379	chore: drop the gitleaks ignore entries that matched nothing ... The three-segment entries in .gitleaksignore were meant to cover the mock licence pair, but a fingerprint is commit:file:rule:line, so file:rule:*** never matched anything - and the file does not need covering anyway: gitleaks detect --no-git --source . --redact (the CI command, on this tree) no leaks found gitleaks protect --staged --redact (after touching mock-licence.json) no leaks found A full-history detect over 1088 commits reports 58 findings, none of them in mock-licence.json - they are an old viewdata.js commit, .npmrc and mock-storage/licence.json, all outside the tree CI scans. Removing the file is more honest than keeping an exception that guards nothing; if a future edit to the pair does fire, the commit fails and the real fingerprint can be added then.	2026-10-26 09:53:47 +00:00
dc	a07728be2b	refactor(sites): bundle the site licence instead of minting it ... The published sites get the same key pair on every deploy, committed as sas/mocks/mock-licence.json (site_id 123, the mock estate's SYSSITE) rather than generated in the pipeline. The pair sits outside the deployed sync folder, so the CI estate stays unlicensed and the Cypress specs keep exercising the free tier. The Sites job copies the pair into the drive before the snapshot and refuses a pair whose two values are identical, which is how the app spots an HTTP-format key it cannot decrypt in a secure context. The pair trips the generic-api-key scanner, so .gitleaksignore carries the two fingerprints.	2026-10-24 22:18:07 +00:00