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

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

On 10/01/2014 03:34 PM, Jim Perrin wrote:
>>> 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.

I am trying to do something with spacewalk that doesn't have any of
these implications.  Regardless, the yum plugin has more potential to be
useful for the vast majority of CentOS users than harmful, in my opinion.

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

This is not a valid use case of the software in the first place, as
Johnny has indicated.  CentOS isn't testing the updates in cases of
pinning to a specific release and updating selectively.  If you don't
test or plan for that to work, then this case is also not really
important either.

Johnny already said there's no guarantee the security updates even
provide security in that case, so maybe this whole talk of the plugin is
irrelevant for this entire pinning to specific release use case.

If we ignore that case, it's still useful in the supported use case of
updating packages within the same release version, in the plugin and in
all other systems that make use of the data.

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

I am not ruling anyone out, this feature simply doesn't apply to their
circumstances.  Yet, it still benefits other people to have it.

They are already using the software in a way that is not supported or
recommended, by several statements already made in this thread.

My interest is in running the software in the supported and recommended
way, with all updates installed, but I am still interested in knowing
what I'm updating and why.  That's a huge part of having this data exposed.

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

Yes.  I am not here because of that plugin. I am here because other
things use this data beside the thing that people shouldn't be doing anyway.

No one brought up the plugin in the previous thread.  I just got into
this one because it is another thing that can use this data, and someone
asked what it would take to make that plugin work.

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

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?

I suspect they're just providing the information and letting users make
their own decisions on it.  Fedora doesn't even keep multiple updates on
the mirrors during a release cycle.  They only leave the latest version
of each package in their updates/ directory.

I'm not trying to make the argument that because one distro does
something, it must be good.  However it seems to be doing what it's
supposed to in these cases.  I use Fedora 20 and having the update
manager remind me that I should update because one of the packages has a
security impact is better than never having that data at all.

- -- 
Kevin Stange
Chief Technology Officer
Steadfast | http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQsbRgACgkQkd/BoeKjg0j12gCgmPIlHlpzzBLsEC0fi/XB76gn
054AniT07vOv49F+28S/mH1y5IDQ00J5
=phpg
-----END PGP SIGNATURE-----