[Mageia-dev] Meeting for secteam start

Sat Apr 16 10:10:36 CEST 2011

 On Fri, 15 Apr 2011 08:35:40 -0400, Stew Benedict 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"
+
+ I would personnaly think we should have something as open as possible :
+ - people could learn from looking on how thing goes ( quite important 
+ to make sure new
+ blood can come in )
+ - not all updates requires secrecy, and I think that most doesn't ( ie, 
+ use
+ public POC, public patches, or are simply not security related )
+ - this would put less pressure on sysadmins to be sure security is not 
+ breached
+
+ So try to be open by default, except if we cannot for some specific 
+ case ( embargo, non public
+ POC ). This would requires :
+ - acl on task tracker ( likely bugzilla )
+ - some policy about declassification ( ie open issues after publication 
+ if the POC can be published,
+ or restrict access )
+
+> Old Process:
+>
+> * monitor vendor-sec, discuss vulns, patches, negotiate release 
+> schedule,
+>    also watch other distro updates, for things we may have missed
+
+ We could ask to maintainers to help on that regard,
+ or, like proposed for mageia-app-db and package testing, have a list of 
+ people
+ dedicated on gathering such informations. For example, someone say "I 
+ take
+ care of watching security for libreoffice and will warn secteam if
+ something need to be done".
+
+> * 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)
+
+ I would propose to have a policy of using system wide library and do 
+ not
+ allow bundled copy ( but this would be likely annoying for some case ).
+
+ And also, if you need some specific support on Sophie, do not hesitate 
+ to ask.
+
+
+> * 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
+
+ Depend on the effort, and the software. While I think minimal change is 
+ good,
+ not everybody agree so we should discuss to find a common ground or a 
+ policy.
+ 
+> * 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
+
+ This mean that we need to make sure packages are easy to rebuild. But 
+ iurt
+ helped a lot on that regard.
+
+> * 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
+>
+> * 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.)
+
+ This would be doable with youri, so we need to do some kind of wrapper 
+ around this to
+ take in account the advisory. Something that would be needed too is a 
+ database
+ of such advisory ( and so we can start to give id of such advisory such
+ as MGA-2011-001, etc ).
+-- 
+ Michael Scherer
+