On Thu, 2011-02-24 at 14:28 -0500, R P Herrold wrote: > On Thu, 24 Feb 2011, Cal Webster wrote: > > > java-1.6.0-sun > > non FOSS, non-source provided, no? This is in an addon > channel in RHEL, and so far as I know we have never shipped > such You're right - shouldn't have listed that one. I manage both RHEL and CentOS machines so this came up on the radar. > Of the others the wireshark update is a periodic update of > some edge case dissectors [these developers are quite good > about releasing time based 'fixes' for their tool -- a > different model than upstream, but perfectly valid], and if > nominally remotely exploitable, as a practical matter, not a > material threat Agreed. We don't use most of the dissectors that get called out either and it's easy to disable them. However, our organizational directives require full IA compliance so I have to show due diligence in resolving every vulnerability. For those that cannot be resolved I must supply work-arounds to mitigate them and a plan of action to resolve it in the end. > The kerberos update crossed vendor-sec, but seems again to be > an edge case hole Not critical for us since none of our engineering networks touch the Internet. If I had a public facing server, though, I'd hate to have to wonder if I might be one of those "edge cases". > The pgsql update is nominally exploitable, but any sensible > environment uses iptables and network segment isolation rather > than adding a world listening daemon True. Any enterprise operation that doesn't take such basic security precautions is asking for trouble. Still, the IA Gestapo doesn't make such distinctions. > I have commented earlier on my distress at the openjdk > update NOT crossing vendor-sec. This said, again, who in > their right mind exposes an unprotected Java listener > application to the wild? I don't disagree with you. Those who evaluate CVE's for applicability to an enterprise don't often have the technical background to distinguish between a practical and theoretical threat. For them, and because of the way $#!+ rolls downhill, myself the vulnerability "must be addressed." > I saw that another in the project mentioned 'bypassing' the > 5.6 respin and testing delays for truly exploitable matter. > The potential 'bind' updates dos attack vector turned out not > to affect anything CentOS has shipped in base and updates, and > so was a 'false positive' as prior discusseio here has noted > > If one wants SLA and deterministic intervals between > announcement and release, it is just not that hard to set up > one off building and updates from released sources upstream, > and so one can have it at the price of a little learning and > experimentation. When things settle a bit in my org and CentOS I'd like to do just that, if for nothing else than the instructional value. > Alternatively, CentOS releases promptly on the usual norm, and > during 'point' update times, falls back to trying to avoid > 'dependency skew' problems by considering the potential > disruption for millions of machines each needing manual > depsolving intervention, vs. getting the nest update build and > QA's and out the door in a durable fashion. Until this 3-way, back-to-back release (4.9, 5.6, 6.0) updates were plenty prompt for me. I totally understand the issues behind the delays. > If that is not 'quick enough', see the prior paragraph about > self-building; or seek a vendor who will sell you the SLA you > deem you require. This is a simple 'build vs buy' decision Thank you for your cordial, detailed reply. We do have a standby OSS support contract based on hourly rate but only intend to use it for true emergencies. > [I might note that I have seen NO filed bug in the CentOS > tracker asserting a need for any of the listed updates on an > expedited basis] Is that how it's done? Until now I haven't paid much attention to the process. No need since updates were fairly swift after upstream release. I report bugs directly upstream via our RH Support entitlement. I'm not sure any such assertions from me would carry much weight anyway. Even if they did I'd imagine there wouldn't be much spare manpower to act on it at this point. > -- Russ herrold > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos