Per the ASF Security Process, you must not make information about a vulnerability in your own code public until it is formally announced at the end of that process. That means, for example, that you should not create a public Jira ticket to track the issue, or a public GitHub issue, since those would make the issue public. Messages associated with any commits should not make any reference to the fact that it fixes a vulnerability.

This does not mean you can't privately reach out to trusted individuals to help out with specific issues - see Getting help handling security reports.

Use the regular public workflows, but keep security impact obscured

To bridge the gap between working in private and our public approach to writing software, generally the recommended approach is to still use the public commit and review process, but without leaking the security impact of the change. Best is when you can combine the security-relevant change with a general cleanup or refactor that obscures it. Alternatively, for the kind of issues that are easy to find with vulnerability scanning tools, it might be inevitably obvious that a given change is a 'security-related' change, but you could leave the fact that this is actually an exploitable vulnerability rather than a 'defense-in-depth hardening improvement' obscured.

In any case, once the fix is public, there is a chance that 3rd parties will realize the security impact, so it is wise to start planning your next release without too much delay.

Preparing patches in private

To reduce the time the (obscured) fix is publicly visible, it can be helpful to discuss the patch on your private list, and only move it to the public process closer to the release. Note that the commit appearing shortly before a release is also a signal to observers, though, so use this method with some care. If you want, Infra can set up a private svn or git repo for you for limited-time private coordination on the fixes within the PMC. For collaborating with reporters, sending around patches is still the easiest method - we've evaluated GitHub PVR for this but found it lacking.

Working and voting fully in private

In rare situations it can be needed to work and vote fully in private.

The Security Team generally discourages this: in the vast majority of cases the public workflow above is acceptable, and it is not obvious that working fully in private meaningfully improves the situation. That said, in cases where:

  • there is an unusually high risk of damage when the fix leaks prematurely
  • it is impossible to obscure the security impact
  • it might not be possible to perform a release on a short timeframe

... you can work 'fully' in private by discussing the patches on your private mailinglist and committing them 'just before' the release. Note that changes getting committed without the regular transparent process 'just before' a release might also highlight them to malicious observers.

For highly sensitive situations, think Log4J CVE-2021-44228 class events, you might even want to do a shorter public voting period. In such a case you'd ideally do a 'private' coordination / voting / staging round within the PMC to make sure everything is in place and ready to go, so you can responsibly shorten the public vote. See https://lists.apache.org/thread/ckr7t4qohcwlk0cz0zf8l39op6mtjgop for some background.

  • No labels