[CentOS-devel] yum-plugin-security and shellshock

On 10/02/2014 03:39 AM, Karanbir Singh wrote:
> On 10/01/2014 10:07 PM, Kevin Stange wrote:
>> Somehow this information is apparently useful, supported and functional
>> in Fedora and SL.  What are they doing to make sure it's not half-baked
>> and broken?  Anyone from SL or Fedora here that could answer that question?
> 
> 
> Fedora is a complete enclosed distro - their proposition is different.
> For SL - they publish the metadata and hope for the best, maybe that is
> fine with their userbase but winging it and keeping fingers crossed is
> really not how I'd want to run my systems.
> 
> While there is still a firewall between us and the RHEL QE / RelEngg ;
> but based on the conversations we've had and what I've seen happening -
> its pretty clear the the SL guys are pushing confidence around things
> that they need to own - and as far as I can tell there is no effort to
> actually validate any of it; even to the point that when heartbleed
> happened - I had to go remind them that every SL version and every user
> instance was exploiteable; unlike RHEL and CentOS where only folks who
> had updated in the few weeks leading upto the issue being reported.
> 
> If you want to see this issue resolved, then blindly throwing something
> over the wall and hoping for the best isnt the way to do it - there are
> fairly tangiable pieces of work that need to be done, find the time, do
> the work. We can all gain from it.
> 
> Besides, if its a case of winging it, why not wing it with a 'yum update
> \*' - atleast you are then winging it with a tested process ( upstream
> and to -some- extent in centos.org too ).

I don't do a yum update *, I review all update notes, and I update the
trivial packages in one pass and a separate pass for each component that
I believe might cause a system problem.

I would like to help add updateinfo.xml but I don't have a connection to
the release process where I understand *how* I can inject this behavior.
 Where can I store the errata metadata during the release so that it's
able to be persistently available for regenerating the current version
of updateinfo.xml?

I'm asking to make an actual change to your update release process, so
if you guys are fighting with me about the very idea of even having this
information, I feel like there's very little chance you would actually
be willing to integrate the new steps.  If I haven't got any reasonable
agreement that this is a good thing first, then any effort I put in is
arguably pointless.

I might as well keep my ugly mailing list scraping hack, even though it
doesn't always work right, because it's better than a lot of effort that
never gets off the ground.

I am willing to make the effort but the release process is still
somewhat opaque to me, and I need some buy in from people releasing the
updates if this is actually something we can realize.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688