MeedyaDL ships with a validated component support matrix — a pinned range of versions for every external dependency (Python runtime, GAMDL, FFmpeg, mp4decrypt, N_m3u8DL-RE, MP4Box, MediaInfo). We only verify the security and functional behaviour of these components within those ranges.

• The current support matrix lives in README.md and is the canonical, user-facing reference.
• The machine-readable source of truth is src-tauri/tool-versions.toml. Bumping a component's range requires a code change, review, and a new MeedyaDL release.
• GAMDL specifically is bounded by [gamdl] maximum_tested_version so update prompts are suppressed when upstream ships beyond the validated ceiling. Users can still install newer versions manually but will see an activity-log warning and lose our support guarantees until the next MeedyaDL release validates that range.

Running MeedyaDL with components outside the listed ranges (e.g. a manually installed newer GAMDL, or a system-PATH FFmpeg below our floor) is not a supported configuration. We will triage bug reports against supported versions first, and may decline to investigate issues that do not reproduce inside the documented range.

If you discover a security vulnerability in MeedyaDL, please report it responsibly:

1. Do NOT open a public GitHub issue for security vulnerabilities.
2. Preferred — GitHub Private Vulnerability Reporting: submit a report via the MeedyaDL private advisory form. This keeps the report invisible to the public, lets us collaborate on a fix in a private fork, and issues a CVE on publication.
3. Alternative — Email: send details to the repository maintainers via the email listed on the MWBMPartners GitHub organisation profile.
4. Include: a description of the vulnerability, steps to reproduce, affected MeedyaDL version(s), and any potential impact.
5. Response time: we aim to acknowledge reports within 48 hours and provide a fix within 7 days for critical issues.

MeedyaDL implements the following security measures:

• Path traversal protection in ZIP and TAR archive extraction

• URL validation prevents CLI flag injection in subprocess calls

• INI injection prevention via newline sanitization in config values

• HTML sanitization in markdown rendering (rehype-sanitize)

• Credential redaction in all logging, exports, and crash reports

• Atomic file writes for settings and queue persistence

• Field-level validation on imported settings/queue files

• No shell interpolation — all subprocess calls use parameterised arguments

• Content Security Policy configured in Tauri for the webview

• Secrets stored in OS keychain (not on disk)

• SHA-256 checksum verification for downloaded dependencies

• GitHub Actions hardening: all actions pinned to immutable commit SHAs

• cargo-deny licence scanning and source allowlisting in CI (org-level [sources.allow-org])

• CodeQL static analysis for JavaScript/TypeScript and GitHub Actions, with the security-and-quality query suite enabled

• GitHub Advanced Security features: Private Vulnerability Reporting, secret scanning + push protection, and Dependabot security updates are enabled on the repository

• Dependabot version updates — weekly PRs for npm and cargo ecosystems (security updates are delivered immediately out-of-schedule)

• Activity log memory bounds — capped at 10,000 entries to prevent unbounded WebView memory growth

• Updater artifact signing — .app.tar.gz.sig signature files verified by Tauri updater before installation

• IPC command rate limiting — sliding-window rate limiter on sensitive commands (downloads, updates, cookie imports)

• Settings file integrity — SHA-256 checksum verification detects external modification

• Pip install verification — post-install audit trail logs package location

The Tauri updater uses an Ed25519 signing key (TAURI_SIGNING_PRIVATE_KEY) to sign update artifacts. All updates are verified against the public key embedded in tauri.conf.json.

1. Revoke the compromised key: remove TAURI_SIGNING_PRIVATE_KEY from GitHub Secrets immediately
2. Generate a new key pair: npx tauri signer generate — store the new private key securely
3. Publish a manual recovery release:
   • Update tauri.conf.json → plugins.updater.pubkey with the new public key
   • Build and release manually (the in-app updater cannot deliver this release since the old key is revoked)
   • Users must download this release from GitHub Releases manually
4. Communicate the incident: publish a GitHub Security Advisory explaining the compromise, affected versions, and recovery steps
5. Subsequent releases: once users have the recovery release with the new public key, normal auto-updates resume

• The private key is stored only in GitHub Actions Secrets (encrypted at rest)
• No developer has the private key on their local machine
• Consider maintaining a backup key pair stored offline (printed QR code in a secure location) for disaster recovery

MeedyaDL is an open-source tool that interfaces with official media platform APIs using user-provided authentication credentials. MeedyaDL does not host, distribute, or store any copyrighted content.

• Can control: the application's source code and distribution
• Cannot control: how users use the tool, what content they download, or their compliance with platform terms of service

If you are a rights holder and believe MeedyaDL facilitates infringement of your copyrighted work:

1. Contact: Email the repository maintainers via the email listed on the MWBMPartners GitHub organisation profile
2. Include: A clear description of the copyrighted work, the specific concern, and your contact information
3. Response: We will acknowledge your request within 48 hours and respond substantively within 7 business days

If you believe a takedown request was filed in error, you may submit a counter-notification to the same contact email with a statement of good faith belief and your contact information.

This security policy covers the MeedyaDL desktop application and its build/release infrastructure. It does not cover third-party dependencies (GAMDL, FFmpeg, etc.) — please report issues with those to their respective projects.