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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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:
>>> 
>>> <snip>
>>> 
>>> 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
>> 6.5.
> 
>> 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
> useful.

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
provides.


> 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
another matter.


- -- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJULGVMAAoJEBbHyC76Ca13hRQP/iQg0GUt1mzpO8WfJpRxCukd
hOmPGqlP4Jw/DSS6ZNRAdsM8RMbLu0ekEnRuJfXl6a7rWfWys1HYZXg1yidoqY7j
/X4E4MAcQ9JroNgJceOh3RGWbmR2xwAY+x/TW524RXPs74DXWq8KdDjcHaAuU66z
GJ0/GpvqXjPIAcdwD2fmSJV/3J4Qq7TuDltjJdKw04QstkWpVfaTcXCSkps/5Eet
nQkO6okdaAFiUQBRyGTNYgD9f4+LLeNU0Of3xPFbzRogpHijOmD+WOWCQ4hZIsl3
PUnSTWZVqHW67osTYH+jR7AcQ2fVqyacqWAJZpRLsm8PYTdsPeu/GAzQxHHef486
LcGtAeEiyEYcJKhLOSqfnpntJ1bdpFxLqdaU+TYXib5CydgIYh5msy1KbN53RUL/
OrN75hqFSUuqeO2qT7fsjjGTc6YD7sXBRv0zQSqjc11mJ83jkl9+PYOONKqMMyW/
VbWHwvxfMmF6MYyxJrAblLZq37hDyMShNxSVL2eMsOw3erK7Q5uz0f8CdP+mMmdK
LCvwgr0wxdSChwrtngR9tgysU/zT0/GMRFPGUJq/I+d9obahJ+5BSAbUb02ZLWO4
F+q1Ep1Rgt0O8WUrz7hcP9md3Jha/XG/kxP9yjGjxvpzJ2QM5tiEItr+MYRxK8z/
03rnxFJC2jBmRhvHX/0p
=86I9
-----END PGP SIGNATURE-----