Security Releases - Update pre-release communications workflow
Synopsis: This issue aims to organize discussion about security-releases and the practice of giving a pre-release announcement or heads-up. The aim is to produce greater clarity/consistency in the final policy without producing a significant on-going admin work.
Considerations:
- Security releases have greater urgency than typical releases.
- Consumers of these releases often have distinct/independent deployment processes (the costs of which vary widely). Consequently, the heads-up can be quite useful in arranging capacity in advance.
- The heads-up can also be used ill - helping blackhats arrange capacity to exploit vulnerabilities before they're widely fixed.
- Mandating a fixed time-frame for a headsup would likely increase the turn-around time on security issues, and the current regimen already encourages poor turn-around time.
- The broader industry has examples where (a) security releases have adhoc scheduling, (b) security releases have specific/advanced notices, and (c) security releases have a "window" policy but no specific notices.
Approaches:
-
(
1️⃣ ) Status quo:-
What: Formally, the current policy treats the first+third Wednesday as windows in which we may do security releases, and there is no formal policy of giving heads-up. However, there are informal practices of (a) sending heads-up to
civicrm-dev@
and random MM channels (b) preferring third Wed over first Wed. - Pro: The informality and obscurity of the announcements feels like it mitigates the concern about blackhats using this information systematically. (That may or may not be true.)
- Con: It fosters an expectation of announcement, even if there is no guarantee of announcement.
-
What: Formally, the current policy treats the first+third Wednesday as windows in which we may do security releases, and there is no formal policy of giving heads-up. However, there are informal practices of (a) sending heads-up to
-
(
2️⃣ ) Kill the informal headsup:- What: Retain the current window policy, but stop the informal practice of sending heads-up.
- Pro: Consistent behavior. Less admin overhead. No false expectations.
- Con: Harder for downstream to mobilize.
-
(
3️⃣ ) Formalize with one medium for headsup:- What: Update the public policy to say that we give a headsup. Specify one medium for announcements - it will only and always go to the "Security Notifications" mailing list.
- Pro: More reliable and more fair
- Con: Easier for blackhats to mobilize.
- Issue: Should sort out the edge-case where "we have a security patch that's ready to go, but that only came a couple days before the window, so we have to choose to choose lesser evil of... waiting an extra 2-3 weeks for another window or giving short/limited/no notice.
Meta
- If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
- Related: Security Releases - Update post-release communications workflow