[Mageia-dev] Meeting for secteam start

[Michael Scherer]

 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