A+BPolicy

Security

Open DJ writes to working DJ libraries and handles live credentials, so a sloppy bug could corrupt a library or leak a token. This page is the launch security policy: how to report, what is in scope, and what guards the writes. It is adapted from SECURITY.md; at 487fa677d7 that file still names v1.0-rc1 and a master branch and has no email route; its launch update exists on a branch and is not merged yet.

ADeck A / Report

Report privately.

Please do not open a public issue, discussion or pull request for a security report. Public disclosure before a fix puts every user at risk.

  1. Once private vulnerability reporting is enabled on the public repository, use its Security tab, Report a vulnerability, to report privately. A report there is visible only to the maintainers. For when the public mirror opens, see the Contributing page. There is no public issue tracker at launch.
  2. If you cannot use GitHub, email hello@open-dj.com with "security" in the subject; that address works only after its forwarding is verified. Until either route is open, do not post exploit details publicly. Leave exploit details and credentials out of that first email; the reply gives you a private channel.
  3. If you need an encrypted channel or a live credential handoff, say so in your first report.

Include

  • A clear description of the issue and the impact you observed.
  • Repro steps or a minimal proof of concept.
  • The commit SHA or version you tested against.
  • Whether you believe the issue is already public.

The policy commits to acknowledging a report within 5 business days.

Coordinated disclosure

A 90-day window by default, measured from the day the report is acknowledged:

  1. Acknowledgement, triage, severity.
  2. Investigation, fix, regression test, internal review.
  3. Release the fix, publish an advisory, credit the reporter with their consent.
  4. If no fix has shipped, a short public advisory with any workaround.

The window can be shorter or longer when the situation calls for it: active exploitation, upstream timing, or a risk of library corruption. No bug bounty is offered. Open DJ is an alpha and a personal project by Alex Foster.

Supported versions

Only main and the latest Open DJ 1.0 alpha release receive fixes. A fix ships as a new alpha, offered by the in-app updater.

  • Latest Open DJ 1.0 alpha (to be tagged app-v1.0.0-alpha.N): current public release. Security updates: yes.
  • main: rolling development branch. Security updates: fixes land on main when ready, then ship in the next alpha.
  • Earlier 1.0 alphas: superseded. Security updates: no; please update.
  • v1.1.1 and the 0.1.x builds: internal test builds of the app. Security updates: no.
  • The April v1.0 and v1.0.1 library toolchain: superseded by main. Security updates: no.
BDeck B / Scope

What is in scope.

In scope

  • Any code that writes to a DJ library: the rekordbox and djay write rails, the Serato and Traktor writers, the shared state database, and the USB and Pioneer export paths.
  • The six-rail safety pattern itself. A bypass of any rail on a destructive path is in scope.
  • Handling of live credentials: token leakage, logging of secrets, or reading secrets from the wrong source.
  • The engine daemon, the web UI and the launcher when bound to the default loopback address. Issues that need a non-default bind address should say so.
  • Supply-chain issues in code vendored into the repository.

Out of scope

  • Upstream dependencies: report to the upstream project and link its advisory.
  • Hardening requests with no exploit, such as asking for a rate limit.
  • Findings that need an attacker who already has shell or filesystem access to the Mac. Local root is treated as game over, and the rails are designed with that in mind.
  • UX issues in rekordbox, djay Pro, Serato or Traktor themselves. Those belong with the vendor.

What guards a write.

The README's rule is that every destructive write to a DJ library goes through six rails, so no single mistake can corrupt a library. The installed Mac app clears the write switch before its engine starts, so it will not write to your rekordbox library, a Pioneer share or a USB export; its one library write is a djay playlist write-back, which runs only after you confirm it and backs up the playlist first. From a source checkout, rekordbox and djay writes go through the rails and rekordbox writeback is off by default; the one exception is undo of an earlier write you allowed. The Traktor writer has only a dry run and two explicit flags, with no running-app check, backup, atomic write or read-back. The reference implementation, apps/sync/safety.py, covers rekordbox and djay writes and lists seven rails: they do not include the dry-run default or the atomic write, and they add a reason tag on every write and an iCloud sync check for djay. Serato writes have their own guard. The launcher's Traktor append refuses while Traktor is running; the Python Traktor collection writer has no running-app check. One known gap: in that module a missing pgrep counts as "not running", where the README says it should stop.

  1. ConfirmYou type a non-trivial confirmation string.
  2. App checkIt stops if the target app is running: rekordbox and djay in the shared module, Serato in its own guard.
  3. BackupA timestamped backup of every file about to change.
  4. Dry runThe default. A live write needs two explicit flags.
  5. AtomicWrite to a temp file, then rename. Never truncate in place.
  6. Read backVerify the write, and emit a script that reverses it.

The engine listens on loopback (127.0.0.1) only, on a port claimed per checkout or chosen per run (the start command prints the address), and has no authentication of its own (README). Anything that can run code as you on your Mac can reach it, which is why local access is out of scope above.

Error reports strip library content and file paths before anything leaves the machine, and nothing leaves until you accept the test-user terms. Details are on the privacy page.

A / Parity
Beyond / B { type: 'crossfader', value: 0.50 }