Daniel Miller takes the security of his software seriously. This policy applies to every repository in the daniel-miller account unless an individual repo overrides it with its own SECURITY.md.
Do not open a public issue, discussion, or pull request for security vulnerabilities. Public disclosure before a fix is available puts users at risk.
Report vulnerabilities through one of the following private channels:
- GitHub private vulnerability reporting - preferred. Open a report from the affected repository's Security tab, then click Report a vulnerability.
- Email - send details to contact@danielmiller.ca.
When reporting, include:
- The affected repository, version, or commit.
- A description of the vulnerability and its impact.
- Steps to reproduce, or a proof-of-concept if available.
- Any suggested mitigation or fix.
- Whether you intend to disclose publicly, and on what timeline.
| Stage | Target response time |
|---|---|
| Initial acknowledgment | Within 3 business days |
| Triage and severity assessment | Within 7 business days |
| Status updates | At least every 14 days while the report is open |
| Fix and disclosure | Coordinated with the reporter, typically within 90 days of triage |
We will:
- Confirm receipt of your report.
- Investigate and reproduce the issue.
- Determine severity and affected versions.
- Develop and test a fix.
- Release a patch and publish a security advisory.
- Credit the reporter in the advisory, unless you prefer to remain anonymous.
Unless a repository's README.md states otherwise, only the latest release of each project receives security updates. Repository-specific support windows take precedence over this default.
In scope:
- Source code and release artifacts published under the daniel-miller account.
- Official deployments and services operated by Daniel Miller.
Out of scope:
- Third-party dependencies (report those upstream; we will track and update once a patch is available).
- Forks or modified distributions not maintained by Daniel Miller.
- Issues requiring physical access, social engineering, or already-compromised user accounts.
- Denial-of-service attacks, automated scanner output without a working proof-of-concept, and theoretical issues with no demonstrable impact.
We will not pursue legal action against researchers who:
- Make a good-faith effort to comply with this policy.
- Avoid privacy violations, data destruction, and service disruption.
- Give us a reasonable opportunity to remediate before public disclosure.
- Do not exploit a vulnerability beyond what is necessary to demonstrate it.
Once a fix is released, we publish a GitHub Security Advisory on the affected repository describing the issue, affected versions, and remediation steps. Reporters are credited unless they request otherwise.