#5650 HIGH Update.: Ensure upstream Fedora bugs fixes/security updates for packages we use...

[Zarro Boogs per Child]

#5650: Ensure upstream Fedora bugs fixes/security updates for packages we use...
---------------------+------------------------------------------------------
  Reporter:  jg      |       Owner:  dgilmore
      Type:  defect  |      Status:  new     
  Priority:  high    |   Milestone:  Update.1
 Component:  distro  |     Version:          
Resolution:          |    Keywords:          
  Verified:  0       |    Blocking:          
 Blockedby:          |  
---------------------+------------------------------------------------------
Changes (by jg):

 * cc: krstic, mstone (added)


Comment:

 I gather from IRC discussion these are a backlog of packages that have
 been gradually hitting joyride from upstream, but not made update.1.

 Given the list of packages, many of these are likely security updates.
 Our lack of insight into upstream fedora changes, however, needs repair.

 At this point in our release cycle, at most we should be accepting
 security patches or fixes to bugs we have ourselves observed in update.1
 itself. Security updates are vetted with extreme care, and we'd have to
 face them anyway.

 1) we need to get our build announcer to extract the information in the
 RPM as to what the Fedora upstream change is, so we see these in ways
 we'll notice.

 2) There are a number of these packages we must investigate very carefully
 asap: python, matchbox to name a couple that are central to us.  Though
 likely innocuous (we possibly would have noticed) we might not notice and
 get bit later, so homework is in order.

 3) from this date out, update.1 builds should not be getting anything from
 upstream F7 without explicit individual action. (which I believe is
 already the case).

 4) we need a process by which security and other fedora bug fixes get
 routed to the right person in OLPC for review.  Dennis is on the fedora
 security mailing list; I'm on the X.org security mailing list: we should
 cover other core technologies as well: e.g. python, firefox(!) to name a
 few.

 Dennis, I think the action items here are mostly on you, except for the
 analysis of any changes (as I said, I'm much more concerned with the non-
 security changes that may be occurring), though we should not rely
 entirely on upstream there anyway.

 The action item on me is ensuring we have representation on the security
 mailing lists of the key upstream projects, essential when we are working
 with upstream development (e.g. X.org, firefox) and running more recent
 versions than are in mainline distributions.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5650#comment:2>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system