From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110415/004003.html | 109 ++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110415/004003.html (limited to 'zarb-ml/mageia-dev/20110415/004003.html') diff --git a/zarb-ml/mageia-dev/20110415/004003.html b/zarb-ml/mageia-dev/20110415/004003.html new file mode 100644 index 000000000..e2327e5f7 --- /dev/null +++ b/zarb-ml/mageia-dev/20110415/004003.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Meeting for secteam start + + + + + + + + + +

[Mageia-dev] Meeting for secteam start

+ Pascal Terjan + pterjan at gmail.com +
+ Fri Apr 15 18:16:43 CEST 2011 +

+
+ +
On Fri, Apr 15, 2011 at 13:35, Stew Benedict <stewbintn at gmail.com> wrote:
+> 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
+
+I think we need to add them to a list at that point (some tickets somewhere)
+
+> * 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)
+
+And add that info in the tickets as a list of needed actions, or maybe
+have some blocking tickets
+
+> * 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.)
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1