[Feature]: Publisher-authenticated SHA-256 checksums and attestations for browser downloads

Aperta
  • Qualcosa non va?
#43,981 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
playwright, typescript
Ambito
devops, security

Direzione di ricerca

Start by reading the three referenced registry and download files to confirm how archive URLs and revisions are selected. Then trace how Playwright publishes release metadata and browser archives; the issue does not identify an existing checksum or attestation entry point. Done means maintainers define a publisher-authenticated verification procedure or decide how to provide authenticated checksums for the listed archives.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

🚀 Feature Request

Please provide independently verifiable, publisher-authenticated integrity metadata for browser archives distributed through Playwright, such as SHA-256 digests in a signed manifest or verifiable release attestation.

For Playwright 1.64.1 on Windows x64, the following default archive URLs were identified from the browser registry and revision manifest (without environment-variable overrides):

Component Revision Archive URL
Chromium 1248 https://cdn.playwright.dev/builds/cft/156.0.8078.4/win64/chrome-win64.zip
Chromium Headless Shell 1248 https://cdn.playwright.dev/builds/cft/156.0.8078.4/win64/chrome-headless-shell-win64.zip
FFmpeg 1013 https://cdn.playwright.dev/dbazure/download/playwright/builds/ffmpeg/1013/ffmpeg-win64.zip

Could the maintainers please clarify:

  1. Are these the correct official Windows x64 archive URLs for Playwright 1.64.1?
  2. Are official SHA-256 digests available for the exact archive bytes?
  3. Is there a publisher-authenticated source for these digests, such as signed release metadata or verifiable attestations? If signatures or attestations are available, please include the trusted signing-key identity or trust root and the commands required to verify them.
  4. What verification procedure is recommended for security-sensitive or restricted environments?
  5. If authenticated checksum metadata is not yet available, could Playwright consider publishing it for future releases?

Relevant source files:

Example

Example use case: a restricted Windows CI or test environment that must verify browser binaries before installing them into a protected execution directory.

The desired workflow is:

  1. Download the official Playwright browser archives into a temporary location.
  2. Retrieve publisher-authenticated checksum metadata or attestations.
  3. Verify the signature or attestation against a documented trusted key or trust root.
  4. Calculate SHA-256 for each downloaded archive and compare it with the authenticated digest.
  5. Install or publish the browser files only after all checks succeed.
  6. Fail closed if any archive, signature, revision, or checksum cannot be verified.

This would cover Chromium, Chromium Headless Shell, and FFmpeg without treating a locally generated checksum as independent proof of authenticity.

Motivation

The Playwright browser revision manifest identifies expected browser versions, but revision mapping alone does not authenticate the downloaded archive contents.

The npm package signature does not necessarily cover browser archives downloaded separately. Similarly, successful HTTPS downloads, HTTP status checks, and content-length checks do not provide an independently verifiable SHA-256 identity for each archive.

In a security-sensitive environment, calculating hashes from an existing local browser cache is insufficient to establish independent upstream provenance, particularly if the cache was previously writable by untrusted principals.

Publisher-authenticated integrity metadata would allow organizations to build reproducible, auditable, fail-closed browser installation workflows while preserving strict filesystem and access-control policies.

This is a supply-chain integrity enhancement request, not a claim that the listed archives are compromised or that a specific vulnerability has been exploited.

Lingua principale
TypeScript
Stelle
99.1k
Fork
6.8k
Merge medio
17h 6m
PR unite (30g)
306

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/playwright

Tutte le issue di microsoft/playwright

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.