Sorry if I break the thread, just signed back up to the list. Just to kick things off for secteam, I thought I'd list the process as I remember it from when I worked with Vincent for a couple of years. Not to say Mageia needs to follow any of this, and as we're a volunteer organization, I suspect things will be structured a bit differently from a staffing POV than "2 guys mostly dedicated to updates"
Old Process: * monitor vendor-sec, discuss vulns, patches, negotiate release schedule, also watch other distro updates, for things we may have missed * check our srpm database (Vincent later reworked this) for all the places the affected source code may be buried (many packages embed copies of other source) * apply/adapt patches for all supported releases/architectures (may have been published on vendor-sec, or from another distro package, or extracted from upstream) ** when we we supporting several releases, with Enterprise stuff being quite old, reworking the patches at times was difficult ** policy changed over time and these days many things bump up to a new release, rather than patching * build in chroot to preserve the original build env (moved to iurt around the time I left) ** if we had trouble building the package, contact the maintainer for help * acquire or write a POC (proof of concept) to test that the vuln is corrected, if not, re-patch/re-test * test the app for basic functionality, that we haven't introduced regressions ** bugfix updates went to QA for testing, this was a big blocker/delay at times * write advisory text (usually copied from the CVE if there is one, or bugzilla from a bugfix) * upload packages to main mirror, wait a few hours and release the announcement (we had several scripts that facilitated getting packages in the right place, signing them, uploading, etc.) -- Stew Benedict New Tazewell, TN
