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
