DebOps Security Policy

Date drafted


Date effective


Last changed





Reporting a vulnerability

If you think your bug has security implications then please send it to the Current DebOps project Leader and additionally to the maintainers of the affected part of the project. If you can fix the vulnerability (or have already done so) please consider attaching a patch. Please consider using OpenPGP to encrypt reports before sending them. You can find the public keys of the team members in the debops-keyring.

Disclosure process

  1. Security report received and is assigned a primary handler. This person will coordinate the fix and release process. Problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems.

  2. Fixes are prepared for all releases which are still supported. These fixes are not committed to the public repository but rather held locally pending the announcement.

  3. A suggested embargo date for this vulnerability is chosen and potential downstream projects of DebOps are notified. This notification will include patches for all versions still under support and a contact address for packagers who need advice backporting patches to older versions.

  4. On the embargo date, the debops-security list is sent a copy of the announcement. The changes are pushed to the public repository and affected parts of the project are released. Additionally, an GitHub issue is opened against the affected repository on GitHub with the intend to inform people watching the repository.

This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.

Receiving disclosures

The best way to receive all the security announcements is to subscribe to the DebOps Security Announcements mailing list. The mailing list is very low traffic, and it receives the public notifications the moment the embargo is lifted. If you produce packages of DebOps and require prior notification of vulnerabilities, you should get in touch with the DebOps project Leader.

No one outside the core team, the initial reporter or downstream projects will be notified prior to the lifting of the embargo. We regret that we cannot make exceptions to this policy for high traffic or important sites, as any disclosure beyond the minimum required to coordinate a fix could cause an early leak of the vulnerability.

If you have any suggestions to improve this policy, please get in touch for example via the debops-policy repository on GitHub.