[Experimental] Share setup downloads between laptops at Contributor Day

Abierto
  • ¿Algo no está bien?
#562 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
git, javascript, wordpress
Área
desktop, devtools, networking, security

Línea de trabajo

This issue is explicitly experimental and research-only, with no commitment to build. Start by investigating the listed checks: Windows Public-network behavior, macOS Local Network permissions, filtered Git bundles, offline npm installs, and venue client isolation. The USB fallback is described as a possible lower-risk first slice; done is not defined until the research and product scope are decided.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Experimental. Research only. Nothing here is committed to being built.

What problem does this address?

At Contributor Day the Wi-Fi is open, slow, and sometimes down. Some people in the room already have a finished site while others are still waiting on the same downloads: the wordpress-develop clone (~57 MB), npm packages (the largest part), and for Gutenberg the stock WordPress zip (~25 MB).

What is your proposed solution?

An opt-in Contributor Day mode that lets laptops in the room share those downloads with each other, torrent-style.

What would change
  1. A setting, off by default. Stored in the existing preferences next to contributionEvent (src/main.js:3326). When off, the app behaves exactly as today. It switches itself off at midnight.
  2. A sharing server, only while the mode is on. Serves three things by hash: a Git bundle of origin/trunk, npm packages listed in trunk's lockfile, and the stock WordPress zip.
  3. Discovery of other sharers on the local network (mDNS), announced under a random ID.
  4. Downloading from neighbours during setup. Git objects, npm packages (through a loopback registry proxy npm is pointed at) and the zip, each raced against the normal internet download.
  5. Pairing for when the internet is fully down. Scan a code on a neighbour's screen to trust their list of hashes.
How it stays safe

The worry is fair: this would be the first thing the app exposes on an open network (every server today is loopback-only, src/bind-loopback.js). The design rests on one rule: a neighbour sends bytes, never decisions. Your app decides what it needs from a trusted source, and checks every byte against it.

Risk How it's handled
A neighbour sends a tampered file (backdoored npm package) Every file is checked against a hash from a trusted source before Git or npm sees it. The trunk commit from GitHub pins every Git object and package-lock.json; the lockfile pins a sha512 per npm package; wordpress.org publishes the zip's .sha1. A mismatch is thrown away, that neighbour is blocked, and the file comes from the internet.
A neighbour lies about which trunk is current The trunk commit comes from GitHub (a few KB), not from neighbours. Their history is kept only if git merge-base --is-ancestor confirms it's part of real trunk.
Internet fully down, so there's nothing to check against No "trust the majority": one attacker can pose as fifty laptops. You pair with a person you can see by scanning a code on their screen. When internet returns, the app checks their commit against GitHub and warns on a mismatch.
Someone attacks the sharing laptop (path traversal, escalation) The server answers only "file with hash X" from its own list. No paths, so ~/.ssh can't be asked for. Read-only, no uploads, no commands, no PHP or WordPress, size and connection caps, separate process.
The sharer's own work leaks Only upstream content is shared: a bundle of refs/remotes/origin/trunk only, so no ticket branches, WIP commits, pr/N, patches or working tree. Never build/, node_modules, databases, wp-config.php, the GitHub token or Trac cookies. The downloader also discards anything not in real trunk.
Private packages leak from the npm cache ~/.npm/_cacache is shared with any npm on the machine. Only packages whose sha512 is in trunk's lockfile are served, so others can't be fetched or even probed.
Malicious files get unpacked before they're checked Downloads land in a temp folder and are hashed first. Git fetches use transfer.fsckObjects=true and the existing protocol allowlist (src/git-write.cjs:28-40).
Code runs that wouldn't otherwise npm install scripts run for the same verified packages the registry would send. Nothing new executes.
Fake neighbours or flooding Harmless to correctness because of the hash checks. Failing neighbours are blocked; sharers have bandwidth and connection caps.
It runs somewhere it shouldn't (at home, a café) Off by default, no prompts, turns itself off at midnight.
Privacy Announce a random ID, never the computer or user name.
Other behaviour
  • Older sharers still help. A neighbour on an older trunk commit sends its history; GitHub sends only the newer commits.
  • Blocked Wi-Fi (client isolation). Neighbour downloads always race the normal download, so a network that blocks laptops from each other costs nothing. The app can tell a sharer "nobody here can reach you".
USB fallback

For rooms where the network is no use at all. Same rule: the stick delivers files, the app checks them. Nothing listens and nothing is discovered, so this is the lowest-risk piece and could ship first. Organisers could also make kits the night before and hand them out at the door.

Export (from a machine with a finished site) writes one folder:

  • trunk.bundle: a Git bundle of origin/trunk only, so none of the exporter's work.
  • npm/: only packages listed in trunk's package-lock.json.
  • The stock WordPress zip (Gutenberg).
  • manifest.json: trunk commit ID, a hash of every file, and a signature. The exporter's screen shows a short code for it.
  • Optionally the signed app installers, for attendees with no app and no internet. Gatekeeper and Authenticode catch tampering there.

A few hundred MB in total. Format the stick as exFAT so macOS and Windows can both read it.

Import ("Set up from a kit" when creating a site):

  1. Copy the kit to local disk and check every file against the manifest. Nothing is read or run from the stick directly.
  2. Trust root: with internet, the trunk commit from GitHub, so no code is needed. Offline, type the code from the exporter's screen. A code printed on the stick proves nothing, since whoever altered the stick could change it too.
  3. Clone from the bundle, point origin at GitHub, and write the same repo config src/git-clone.cjs writes. Otherwise isLegacySite refuses the site.
  4. npm install --offline against the imported packages; anything missing comes from the registry when online.
  5. Put the zip in the Playground CLI's cache.
  6. An old kit is fine: "Update trunk" fetches the newer commits once online.

Limits: a malicious USB device (one that pretends to be a keyboard) is outside what any app can defend against, so the docs should say to use sticks from organisers or people you know. Offline, trusting a kit means trusting the person who handed it over; the app checks the commit against GitHub once the internet returns.

To check before building
  • Windows treats conference Wi-Fi as a Public network and blocks inbound connections. What does a Windows sharer see?
  • macOS 15+ Local Network permission prompt and NSLocalNetworkUsageDescription.
  • git bundle create on the --filter=blob:none clone without fetching missing blobs.
  • npm install --offline from a copied cache for wordpress-develop, macOS and Windows.
  • How often venue Wi-Fi uses client isolation.
  • Whether the USB export needs Contributor Day mode on, or is simply a menu item.
Lenguaje dominante
JavaScript
Estrellas
66
Forks
20
Merge medio
1 d 18 h
PR fusionados (30 d)
22

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de WordPress/contributor-toolkit

Todos los issues de WordPress/contributor-toolkit

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.