The pg_debver project takes security issues seriously. This document outlines the process for reporting security vulnerabilities, our contact channels, and our expected response timelines.
Security fixes are actively provided for the following versions:
| Version | Supported | Notes |
|---|---|---|
1.x (current: 1.0.0+) |
✅ | Active support |
< 1.0.0 |
❌ | Unsupported |
pg_debver is supported and tested against PostgreSQL 10, 12, 13, 14, 15, 16, 17, 18, 19, and master.
Important
Do not report suspected security vulnerabilities through public GitHub issues, discussions, or pull requests.
If you discover a security vulnerability in pg_debver, please report it privately by email to the project maintainers:
- Hannu Krosing:
hannuk@google.com - Hannu Krosing:
hkrosing@gmail.com
Please include both email addresses on the report to ensure prompt handling.
To help us triage and resolve the issue quickly, please provide as much of the following details as possible:
- Vulnerability Summary: A clear description of the potential vulnerability and its estimated impact (e.g., server crash/DoS, out-of-bounds read/write, memory corruption, arbitrary code execution, privilege escalation, or hash/index contract violation).
- Affected Environment:
pg_debverversion or commit SHA- PostgreSQL version(s) tested (e.g., PostgreSQL 16.4, 17.0)
- Platform / Operating System and architecture (e.g., Debian 12 x86_64, Linux ARM64)
- Steps to Reproduce (PoC): A minimal, reproducible SQL script or reproduction instructions.
- Proposed Fix: Any suggested patch or remediation steps (if available).
- Disclosure Preferences: Let us know how you would like to be credited (name, handle, or anonymous) in release notes and security advisories once the issue is resolved.
We follow a structured vulnerability handling process with the following target timelines:
| Stage | Expected Timeline | Action |
|---|---|---|
| Initial Acknowledgment | Within 48 hours (2 business days) | Maintainers acknowledge receipt of the report. |
| Triage & Validation | Within 5 business days | Maintainers confirm reproduction, assess severity (per CVSS v3.1), and determine scope of impact. |
| Status Updates | At least every 7 days | Maintainers keep the reporter informed of investigation and patch development progress. |
| Fix Development |
14–30 days (Critical/High) 30–60 days (Medium/Low) |
A secure fix is developed, reviewed, and regression tested across all supported PostgreSQL versions. |
| Release & Disclosure | Coordinated (target |
Patched release published on GitHub alongside a public security advisory. |
- Private Handling: The vulnerability report is investigated privately. Fixes and regression tests are developed in a private branch or fork.
- Reporter Verification: When feasible, a proposed patch will be shared with the reporter for confirmation prior to release.
- Release & Public Disclosure: A new release containing the fix will be published, and an advisory will be posted detailing the issue, severity, mitigation, and reporter attribution (if desired).
- Safe Harbor: We consider security research conducted in good faith according to this policy to be authorized. We will not pursue legal action against researchers who report vulnerabilities following these guidelines, avoid privacy violations, do not destroy data, and do not interrupt or degrade production services.