Skip to content

Security: TCeramic/OpenLyricSync

SECURITY.md

Security Policy

OpenLyricSync is a provider-neutral, local-first TypeScript workspace. The core package and CLI do not authenticate with music services, scrape provider endpoints, send telemetry, or accept provider tokens and cookies. This policy covers the repository, release artifacts, CLI, and @openlyricsync/core.

Supported versions

Version Security fixes
0.1.x Supported
<0.1.0 or unreleased commits Not supported; upgrade to the latest 0.1.x release or commit

The supported runtime baseline is Node.js >=22.13 as declared by the current workspace and core package.

Report privately

Please do not open a public issue, pull request, discussion, or social-media post for an unpatched vulnerability. Use GitHub's private vulnerability reporting form:

https://github.com/TCeramic/OpenLyricSync/security/advisories/new

If private reporting is disabled, open a minimal public issue that contains only the words private security report requested and no vulnerability details, exploit steps, credentials, tokens, cookies, personal data, or lyric content. Maintainers will use the repository's private channel to continue the report.

Include, when safe to share privately:

  • affected version, commit, package, and operating system/runtime;
  • a concise impact statement and the smallest reproducible example;
  • exact commands, inputs, and expected versus observed behavior;
  • sanitized logs, stack traces, or screenshots; and
  • whether the issue is already known to be publicly disclosed.

Remove credentials, provider responses, copyrighted lyric catalogs, personal data, and unrelated customer information before uploading evidence. Do not test or target Spotify, NetEase Cloud Music, or another provider through this project; provider integrations are outside the repository boundary.

Response and disclosure process

Maintainers aim to acknowledge a private report within 5 business days, provide an initial triage decision within 10 business days, and share a status update at least every 14 days while work is active. Timelines can change for upstream fixes, embargoes, or reports that need more reproduction data.

We will confirm the affected versions, assess severity and exploitability, create a fix or mitigation, and coordinate a release/advisory when practical. The default coordinated-disclosure target is 90 days after acknowledgement; the reporter and maintainers may agree to a different date. We will credit a reporter in an advisory when requested and when doing so is safe. We do not promise a bounty or a particular release date.

Scope and safe testing

In scope are defects in this repository's code, package metadata, build/release workflow, dependency configuration, and published artifacts. Examples include credential leakage, unsafe parsing, arbitrary code execution, unintended network access, dependency compromise, and release-integrity failures.

Please use a local checkout, synthetic input, and the smallest reproducible test. Do not perform denial-of-service, credential attacks, bulk crawling, social engineering, destructive actions, or testing against third-party music services. Reports that require compromising an unrelated service are outside this policy.

Public fixes

After a fix is available, maintainers may publish a GitHub Security Advisory, release note, or changelog entry with affected versions, fixed versions, impact, and upgrade guidance. Public discussion should wait until the coordinated disclosure date or an earlier date agreed with the reporter.

There aren't any published security advisories