discovery-media-player

Publicly readable without an account at https://github.com/Juli1artha/discovery-media-player. It is the single authoritative repository; there is no mirror or duplicate to create ambiguity about which copy is primary.

Git records the author, the timestamp and the content of every change. Each change reaches main through a pull request whose number appears in the commit subject, so the discussion behind a change is reachable from the change itself. History on main is never rewritten, and a pre-push hook refuses pushes to a branch whose pull request has already been merged, precisely so work cannot silently detach from the recorded history.

Interim work is public before release: every change is pushed to a branch and opened as a pull request, where it is visible and reviewable between releases. Branches are not deleted on merge, and the full commit sequence of each pull request stays in the history rather than being squashed into an opaque single commit.

git, with full public history. https://github.com/Juli1artha/discovery-media-player

Each release carries a unique version in package.json, published to npm under that exact version and tagged in git as vX.Y.Z. The running instance reports the same identifier through GET /api/doc?contract=1, so an operator can tell exactly which version is serving. A release preflight guard refuses a tag that does not match the version the repository declares.

Every release is tagged in git as vX.Y.Z — the current release is v0.1.128 — and each tag has a corresponding GitHub Release at https://github.com/Juli1artha/discovery-media-player/releases. A CI guard refuses a tag that points at a commit which does not belong to main.

Every release has human-readable notes. CHANGELOG.md at https://github.com/Juli1artha/discovery-media-player/blob/main/CHANGELOG.md carries a dated section per version in Keep a Changelog form, and the same content appears on each GitHub Release at https://github.com/Juli1artha/discovery-media-player/releases. A CI guard checks that the version being published has a matching changelog section, so a release cannot ship without notes.

Every release has human-readable notes. CHANGELOG.md at https://github.com/Juli1artha/discovery-media-player/blob/main/CHANGELOG.md carries a dated section per version in Keep a Changelog form, and the same content appears on each GitHub Release at https://github.com/Juli1artha/discovery-media-player/releases. A CI guard checks that the version being published has a matching changelog section, so a release cannot ship without notes.

Users submit defects through the issue chooser at https://github.com/Juli1artha/discovery-media-player/issues/new/choose, which offers a structured bug report form. Blank issues are disabled so every report arrives with the version, the reproduction and the observed behaviour. https://github.com/Juli1artha/discovery-media-player/blob/main/SUPPORT.md states what to include and why, and routes vulnerabilities to email instead of the public tracker.

GitHub issue tracker, three structured forms, blank issues disabled. https://github.com/Juli1artha/discovery-media-player/issues

No bug report has yet been submitted from outside the project, so there is no backlog of unacknowledged reports: the tracker holds a single open issue, an enhancement proposal raised by the maintainer and labelled help wanted with a full scoping analysis. Defects found so far have come from external audits and from CI, and each was answered in the changelog with the version that fixed it. The project commits in SUPPORT.md and SECURITY.md to responding, and vulnerability reports carry a stated 72-hour acknowledgement.

One enhancement request exists — a SQLite backend, at https://github.com/Juli1artha/discovery-media-player/issues/25 — and it was answered in the issue itself with a measured scoping analysis: the number of call sites, the tables involved, what the change would and would not cover, and the explicit reason it is not being done yet. It is labelled help wanted rather than left silent. No enhancement request has gone without a response.

All reports and their responses are publicly archived and searchable at https://github.com/Juli1artha/discovery-media-player/issues?q=is%3Aissue, including closed issues, and pull request discussions at https://github.com/Juli1artha/discovery-media-player/pulls?q=is%3Apr. No account is needed to read or search them.

The process is published at https://github.com/Juli1artha/discovery-media-player/blob/main/SECURITY.md and surfaced from the issue chooser so a reporter meets it before opening a public issue. It gives the address, the expected timeline, the scope of what counts as a vulnerability and what does not, and the design notes a tester needs before starting.

Private reports are supported and are the required channel: https://github.com/Juli1artha/discovery-media-player/blob/main/SECURITY.md directs reporters to email security@3d-discovery.fr rather than open an issue, stating why — instances of this player serve commercial documents, and a public report is a starting pistol. The policy promises acknowledgement within 72 hours and an assessment within 7 days, and offers to agree a disclosure date and to credit the reporter.

No vulnerability report has been received in the last 6 months, so there is no response time to measure. The published policy commits to acknowledging a report within 72 hours and assessing it within 7 days.

npm run build produces everything the package ships: esbuild bundles the browser modules from src/ into server/*.generated.js, tsc emits the compiled bridge and its type declarations into dist/. A clean npm ci followed by npm run build reproduces them exactly, and CI proves it — it rebuilds on every run and fails if the result differs by a byte from what is committed.

npm as the build driver, with esbuild for bundling and the TypeScript compiler for the published types — all standard tools in this ecosystem, invoked through the conventional npm run build.

Every build tool is FLOSS: Node.js, npm, esbuild (MIT), TypeScript (Apache-2.0), and for the test benches vitest (MIT), ESLint (MIT) and playwright-core (Apache-2.0). The container image builds from an official Node Alpine base pinned by digest. No proprietary tool is needed to build or test the project.

An automated suite of 1515 tests across 144 files runs under vitest, which is MIT-licensed, and the suite itself is in the repository under the project's own FLOSS licence. It is split into four benches: the unit and integration bench (npm test), a browser bench driving a real Chromium (npm run test:e2e), a bench against a real PostgREST and Postgres (npm run test:base), and a cost bench under load (npm run test:charge).

npm test — the platform's standard invocation, documented in CONTRIBUTING.md; offline, in seconds, no database or browser required. https://github.com/Juli1artha/discovery-media-player/blob/main/package.json

Measured with the v8 coverage provider over server/, context/ and src/: 83.8% of lines, 78.8% of statements, 81.6% of functions and 70.5% of branches, from 1515 tests across 144 files. Coverage is deliberately not uniform — the security-critical paths carry the densest tests, including the file proxy that fetches a caller-supplied URL server-side, the access wall, share revocation and the presence ceiling, each with tests named for the failure they prevent.

The full suite (~1,900 tests) runs on every push and every pull request, on Node 22 and 24 — plus browser, real-database and load benches on the same trigger. Pull requests are the only way into main, and nothing merges red. https://github.com/Juli1artha/discovery-media-player/blob/main/.github/workflows/ci.yml

The policy is the project's stated one rule, in CONTRIBUTING.md: a behaviour worth keeping is worth a test that fails without it. It is expressed as a format requirement too — a test's name must say what failure it prevents, not that it tests the happy path, and a test whose name does not say that will be asked about in review.

The recent history shows it directly: commits such as test(multi-processus), test(charge) on a thousand-viewer regime, test(charge) on a slowed database, and test(gardes) adding a meta-test that every guard refuses rather than declaring victory on an empty repository. The suite grew to 1515 tests this way, and the guard added for this badge review shipped with 21 tests of its own, covering both what it catches and what it deliberately lets pass.

The policy lives inside the contribution instructions themselves — the exact place this criterion requires. https://github.com/Juli1artha/discovery-media-player/blob/main/CONTRIBUTING.md

Two layers. ESLint runs over bin, context, server, src and build on every push and pull request. TypeScript compiles with strict: true plus noUnusedLocals, noUnusedParameters and noFallthroughCasesInSwitch, checked separately by npm run typecheck. Both are required checks in CI, so neither can be skipped on the way to main.

Warnings are addressed rather than accumulated: ESLint currently reports 0 errors and 0 warnings across the linted tree, and npm run typecheck passes clean. Where a rule is deliberately set to warn rather than error — no-empty and unused caught errors — the configuration carries the reason in a comment, because many paths must degrade quietly rather than stop a document from displaying.

Maximally strict: tsc strict mode plus noUnusedLocals, noUnusedParameters and noFallthroughCasesInSwitch; ESLint at --max-warnings 0. Zero warnings tolerated, blocking in CI. https://github.com/Juli1artha/discovery-media-player/blob/main/tsconfig.json

The design shows it concretely. The core fails closed: a document requiring authentication whose access-wall plugin is absent returns 404 rather than degrading into a freely readable document. Refusals are explicit, so a host cannot mistake refused for unreachable and fall back to its own viewer. Served pages run under a nonce-based CSP. The database is reached only from the server with a service-role key and no table carries an anonymous read policy. Privilege separation extends to CI, where the release workflow declares permissions: {} and grants the narrowest scope per job. SECURITY.md names the file proxy as the highest-value target precisely because it takes a URL from a caller and fetches it server-side.

SECURITY.md enumerates the classes that matter here and how each is handled: server-side request forgery through the file proxy, which is confined to allow-listed storage origins; broken access control through slug guessing, revoked links that still open, or an access wall opening without a valid token; privilege escalation across the host boundary, including leaking PLAYER_HOST_FETCH_SECRET into a URL or a log; and cross-site scripting, treated as a vulnerability because pages run under a nonce-based CSP. The policy also states that a plausible typo which widens a guard is a vulnerability to be fixed by normalising the input — a trailing slash missing from an environment variable already caused one.

Only published, standard primitives from Node's node:crypto and the Web Crypto API: SHA-256 for hashing, HMAC-SHA256 for authenticating share and presence tokens, and crypto.randomBytes, crypto.randomUUID and getRandomValues for token generation. No proprietary or homegrown algorithm is used anywhere, and comparisons of secret-derived values use crypto.timingSafeEqual.

The project implements no cryptography of its own. It calls node:crypto on the server and the Web Crypto API in the browser — both platform implementations specifically designed for the purpose. There is no hand-rolled hash, cipher, or comparison routine in the codebase.

All cryptographic functionality runs on Node's node:crypto, backed by OpenSSL, and on the Web Crypto API in the browser. Both are FLOSS implementations available on every supported platform, and nothing in the project depends on a proprietary cryptographic library.

SHA-256 and HMAC-SHA256 throughout, well above the 112-bit minimum. Tokens and share slugs are generated with crypto.randomBytes at lengths that keep at least 128 bits of entropy, and the HMAC secrets an operator supplies are documented in docs/CONFIGURATION.md as requiring high-entropy values.

No broken primitive is used. There is no MD5 and no SHA-1 anywhere in the codebase — every hash and MAC call names sha256 explicitly, verified across server/, context/ and src/.

SHA-256 and HMAC-SHA256 only; no MD5, no SHA-1, no CBC anywhere in the tree, and secret comparisons use timingSafeEqual. https://github.com/Juli1artha/discovery-media-player/blob/main/docs/SECURITY-PRACTICES.md

The software implements no key-exchange or transport-security mechanism of its own, so there is nothing here in which forward secrecy could be implemented. It is an HTTP handler that runs behind the host's TLS termination — a serverless platform, a reverse proxy, or the host application — and the modern TLS suites those terminators negotiate provide forward secrecy independently of this code.

The project never stores passwords. It authenticates no end user itself: identity is supplied by the host application through the injected context, and the access wall is a host-provided plugin. No password, and no password-equivalent, is written to any table the player owns.

All security-relevant random values come from a cryptographically secure generator: crypto.randomBytes and crypto.randomUUID on the server for share slugs, presence keys and control tokens, and crypto.getRandomValues with crypto.randomUUID in the browser. Math.random is not used for any security purpose.

Delivery is over authenticated channels only. The npm package is published through OIDC trusted publishing, with no stored registry token, and carries a signed provenance attestation binding the tarball to the workflow and commit that built it. Container images go to GHCR with build provenance attestations. Source and release archives are served by GitHub over HTTPS, and git access is HTTPS or SSH.

No hash is fetched over an unauthenticated channel. Dependency integrity comes from package-lock.json, which pins every transitive package with a Subresource-Integrity hash and is verified by npm ci over HTTPS. Container base images are pinned by sha256 digest and GitHub Actions by 40-character commit SHA, each enforced by a CI guard that refuses a floating tag.

There are no unpatched vulnerabilities. npm audit reports 0 vulnerabilities across the dependency tree, CodeQL runs on every push, every pull request and weekly with no outstanding findings, and no vulnerability has been publicly reported against this software. Dependabot proposes updates monthly across npm, GitHub Actions and Docker.

No critical vulnerability has been reported to date. The findings that have arrived — from three external audits in August 2026 — were fixed and released within days, and the trail is public and unedited: the reports in docs/, the follow-up ledger recording what was done, what was decided against and why, and the changelog section for the version that carried each fix.

No credential is present, and a guard now enforces it rather than habit. .gitignore excludes .env and .env., and tools/secrets-en-clair.mjs inspects every tracked file for seven classes of credential recognisable by form — PEM private keys, AWS key ids, GitHub, npm and Slack tokens, Google API keys, Stripe live keys — plus Supabase service_role JWTs identified by decoding the payload, so the publishable key meant for a browser is not flagged. It additionally requires that in any .env file a variable whose name denotes a secret carries no value, which catches the credential with no recognisable form. It runs in CI and in the pre-push hook installed by npm install, so a credential is refused before it reaches the remote. Publishing uses OIDC, so no long-lived registry token exists to leak.

CodeQL analyses the javascript-typescript codebase on every push to main, on every pull request, and on a weekly schedule so that new rules meet old code. The workflow is at https://github.com/Juli1artha/discovery-media-player/blob/main/.github/workflows/codeql.yml, with its configuration in .github/codeql/codeql-config.yml, and the check is required before merge. Beyond it the repository runs typescript-eslint and tsc under strict, plus its own guards that statically parse the workflow YAML and the Dockerfile to prove every action is pinned to a commit SHA and every base image to a digest.

CodeQL with the JavaScript/TypeScript security suites runs on every push, every pull request, and weekly. https://github.com/Juli1artha/discovery-media-player/blob/main/.github/workflows/codeql.yml

No medium or higher severity finding is outstanding. CodeQL reports clean, ESLint reports 0 errors and 0 warnings, and npm audit reports 0 vulnerabilities. The findings from the three external audits of August 2026 were fixed, each with a test that fails without the fix, and the follow-up ledger in docs/ records the ones that were deliberately not done along with the reason.

On every commit, not merely daily: CodeQL runs on every push to main and every pull request, plus a weekly scheduled scan so that rule updates are applied to code that has not changed. ESLint, tsc and the repository's own static guards run on every push and pull request as required checks.

A ZAP dynamic scan runs against the real application on every push — therefore before every release, mechanically. https://github.com/Juli1artha/discovery-media-player/blob/main/.github/workflows/zap.yml

No memory-unsafe language in the produced software: no native addon, no FFI — nothing a memory-safety tool could observe. (A ZAP dynamic scan runs in CI regardless.)

No assertion-compilation concept exists in JavaScript — there is nothing to "enable": runtime checks (guards, explicit refusals) are always active, during dynamic analysis and in production alike.

No medium or higher severity vulnerability has been found by dynamic analysis and left unfixed. The benches currently pass in full — 1515 tests across 144 files — and the issues these benches did surface, including a silent fallback to a costlier heartbeat path when a database migration was missing, were fixed and recorded in the changelog for the version that carried the fix.