After some discussion in September, Quim created T480 in Phabricator[1]. Markus polished up the "Security Release" section of the Release checklist[2] and we agreed to use it as the process for security releases from now on.
Footnotes: [1] https://phabricator.wikimedia.org/T480
[2] https://www.mediawiki.org/wiki/Release_checklist#Security_Release_.28minor_v...
On Nov 1, 2014 8:52 PM, "Mark A. Hershberger" mah@nichework.com wrote:
After some discussion in September, Quim created T480 in Phabricator[1]. Markus polished up the "Security Release" section of the Release checklist[2] and we agreed to use it as the process for security releases from now on.
Footnotes: [1] https://phabricator.wikimedia.org/T480
[2]
https://www.mediawiki.org/wiki/Release_checklist#Security_Release_.28minor_v...
-- Mark A. Hershberger NicheWork LLC 717-271-1084
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
What about marking the bugs as public? That is a step that is often missed and should be done just prior to sending release announcement.
From the list:
" Check for vulnerabilities"
That could use clarification - does it mean check which branches need to be patched? does it mean verify that the exploit doesnt work on newly patched branches? Or perhaps it could refer to some automated testing tool?
Given we want to minimize time between vulnrability being public and release, id reccomend adding a step of run unit tests locally in case they fail, before making jenkins do it publically.
--bawolff
Brian Wolff bawolff@gmail.com writes:
From the list: " Check for vulnerabilities"
That could use clarification...
https://phabricator.wikimedia.org/T1076
wikitech-l@lists.wikimedia.org