[CentOS-devel] yum-plugin-security and shellshock
jperrin at centos.org
Wed Oct 1 20:34:20 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 10/01/2014 02:41 PM, Kevin Stange wrote:
> On 10/01/2014 01:10 PM, Johnny Hughes wrote:
>> On 10/01/2014 12:58 PM, Johnny Hughes wrote:
>>> On 10/01/2014 12:11 PM, Kevin Stange wrote:
>>> CentOS is the community .. why don't you figure it out and
>>> maintain it as a SIG?
> If the idea of a SIG permits managing changes to the core
> distribution's repodata to add this metadata, then it can be a SIG,
> but the SIG will need direct access to the mirror network to
> implement the required changes.
> But I don't think this should be a SIG. It should be part of the
> core product and it should be done in real time when the repos are
> updated and the update bulletins are created.
>> How would we handle this scenario:
>> I user has 6.3 installed, they have never updated. We are on
>> Package abc-1.2.3 is installed on their machine, it is on the 6.3
>> iso that they installed from.
>> Package abc-1.2.4 is a security update and in 6.4.
>> Package abc-1.2.5 is a bugfix only update in 6.5.
>> The guy says .. yum update security only.
>> The info in the xml file says abc-1.2.4 is the right package, but
>> it is not installable from 6.5 .. what happens?
> I'll be honest: I don't care about this scenario at all. My
> spacewalk server would take care of this just by virtue of CentOS
> having the data ever available for these packages and constantly
> keeping itself current.
That's great for you. It misses the larger picture of the distro as a
whole and how many people who are not you choose to use the distribution.
> However, in this case, what would happen would be that 1.2.4 would
> not exist in the updateinfo.xml at all, so the user would receive
> no update for that particular package on the basis of security, but
> would still receive updates for all the other security packages
> marked in updateinfo.xml. Maybe that creates a false sense of
> security, but why have they not been installing these updates from
> 6.3 to 6.5 in the meantime? Perhaps they don't follow the
> centos-announce list and have missed out on all CESAs in the past
> few years. The updateinfo.xml enables continuously keeping tabs on
> security issues as they come up, and it's perfectly effective when
> people are doing reasonable things already with regard to
> selectively installing security updates are caught up to current
> (6.5) distribution.
There's no maybe to it. This *does* create a false sense of security.
Hang out on the forums for a while, or come sit in #centos on freenode
for a while to see how people are installing and using. How many times
have people posted to the list that they MUST (for varying definitions
of the word) pin to a particular release for a vendor requirement, but
they still want updates. Your ideal use case breaks for a wide array
of the users we deal with daily.
> Honestly, if someone is using 6.3 and has not been keeping up with
> security or upgraded to 6.4 or 6.5 by now, it's really already such
> a bad state that I don't think it matters if this should work. I
> don't think it is appropriate to dismiss the entire idea on the
> basis that some people doing unreasonable things won't find it
It's equally unreasonable to arbitrarily rule out a large chunk of the
user base because it doesn't fall in line with your uses.
> My interest in this feature has nothing to do with selective
> updating. That is not my objective and I don't care if it works. I
> am interested in metadata that provides information, so people have
> easier and pervasive access to that data when they perform their
> regular updates to the supported versions of the system.
Then you're choosing to largely ignore the functionality the plugin
> Having the only source of information be the centos-announce
> mailing list is the problem I want solved. There should be a feed
> that makes use of the already existing tools that ship with the
> system, and that is what updateinfo.xml is for.
While I don't disagree, I have no intention of implementing a
half-baked, broken solution that allows users to *think* they're
secure when they're very much not. For individual use cases, this is
easy to solve. to do it properly for the distro itself is quite
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the CentOS-devel