On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote:> On 03/01/2016 09:41 PM, Johnny Hughes wrote: > > BUt the security plugins do not work for CentOS and they never have, > > Peter is correct, you need to run yum update or call out the specific > > packages you want updated. > >I totally understand the necessity of a full system update. However, this begs the question "Why code an option into yum that is of no use?" Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What? Don't spare any gory details either! ak.
On 2 March 2016 at 11:24, Anthony K <akcentos at anroet.com> wrote:> On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote: > > On 03/01/2016 09:41 PM, Johnny Hughes wrote: > > > BUt the security plugins do not work for CentOS and they never have, > > > Peter is correct, you need to run yum update or call out the specific > > > packages you want updated. > > > > > I totally understand the necessity of a full system update. However, this > begs > the question "Why code an option into yum that is of no use?" Was there a > time > when this option was functional? If yes, what caused its removal? Was it > a > system compromise at some big corporation and someone got sued/fired? > What? > Don't spare any gory details either! > > >Specifically it requires errata data within the repo metadata. It exists in yum since CentOS is a RHEL rebuild and upstream provides that errata data for RHEL users. If you set up something like Spacewalk then you can use something like CEFS to import that errata data to make --security work for centos systems. https://cefs.steve-meier.de/ Potentially you could use a combination of his work, a bit of scripting and createrepo to provide your own errata data. *That all being said* apply all errata still applies whenever issues arise ;)
On 03/02/2016 03:24 AM, Anthony K wrote:> On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote: >> On 03/01/2016 09:41 PM, Johnny Hughes wrote: >>> BUt the security plugins do not work for CentOS and they never have, >>> Peter is correct, you need to run yum update or call out the specific >>> packages you want updated. >>> > > I totally understand the necessity of a full system update. However, this begs > the question "Why code an option into yum that is of no use?" Was there a time > when this option was functional? If yes, what caused its removal? Was it a > system compromise at some big corporation and someone got sued/fired? What? > Don't spare any gory details either! >yum does not need to be restricted to vendor repositories. You can add package repositories maintained by anyone, and some of them may choose to distinguish between security and non-security updates, so it is appropriate for yum as packaged in CentOS to retain that feature even if the CentOS repositories themselves do not make use of it. Personally I think it is a dumb option and is in contrast to KISS. KISS says keep your system up to date. RHEL/CentOS works really hard to prevent updates from breaking a system. That's why many of us use it. So it doesn't make sense to not update when an update is available, making security specific updates kind of worthless.
On 03/02/2016 05:24 AM, Anthony K wrote:> On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote: >> On 03/01/2016 09:41 PM, Johnny Hughes wrote: >>> BUt the security plugins do not work for CentOS and they never have, >>> Peter is correct, you need to run yum update or call out the specific >>> packages you want updated. >>> > > I totally understand the necessity of a full system update. However, this begs > the question "Why code an option into yum that is of no use?" Was there a time > when this option was functional? If yes, what caused its removal? Was it a > system compromise at some big corporation and someone got sued/fired? What? > Don't spare any gory details either! > > > ak.It would require 2 things that we currently don't do. 1. Host all the RPMs every built in one place that every update can hit. 2. An errata.xml file that contains information that is NOT open source and not allowed to be gathered by CentOS. (Although James Hogarth provided a link to one elsewhere in this thread) First for #1: We utilize several hundred servers and free bandwidth that they provide that are donated to the CentOS Project to distribute updates. This 'donated network' makes up the DNS names mirror.centos.org, msync.centos.org, and cloud.centos.org, etc. We use this network to distribute CentOS Linux to more than 630 servers (external mirrors) in 85 countries all over the world. We could not provide CentOS for free for the last 13 years if we did not have both the hundreds of donated machines that make up mirror.centos.org (and msync.centos.org) OR those external mirrors. The vast majority of our donated mirror network servers do not have room to host all the RPMs from all active centos versions in one place and to distribute them to the vast external server network. We can't afford to replace the hundreds of donated (free) servers with ones that CAN host that amount of data AND also pay for enough bandwidth to distribute it to the external mirrors. Even if we could, not all the current 635 mirrors would be able to take all that data. This is one of many reasons why there is a subscription price for RHEL. Even if we DID all of that. Other than returning a cou0ple of updates with the yum security plugin command, you STILL need to run 'yum update' to get all the updates as JUST doing the security ones is not supported / does not necessarily fix the security issues. Then there is #2: The information that goes INTO the XML file we would need to generate does not come from the source code from Red Hat Enterprise Linux that we use to build CentOS Linux. It would only from screen scraping places like: https://rhn.redhat.com/errata/rhel-server-7-errata.html BUT, if you go to the 'terms of use' for Red Hat portals .. here: https://access.redhat.com/help/terms/ You will see the definition of "Red Hat Content". While we CAN distribute the software we build (it is open source) .. we *CAN NOT* scrape and/or Distribute content that is *NOT* open source but us copyrighted intellectual property. To the best of our knowledge, the information needed to make up all the information needed to create the Errata XML file requires to make the yum security plugin work is not available in a complete open source way where we would be able to be distributed. That is *WHY* the CentOS team does not copy and distribute any content into our announcements, but only links to open content in our announcements. So, we can not distribute the information that is required in the XML file that would make the yum security plugin work .. *BUT* even if we could, you *STILL* need to run 'yum update' to get all the updates as JUST doing the security ones is not supported / does not necessarily fix the security issues. Hopefully this makes sense. You can instead just look at this: https://lists.centos.org/pipermail/centos-announce/ (or subscribe to the CentOS announce mailing list to get emails) Both of those places will tell you when there is a security update. OR, you can subscribe to RHEL and use the information in the yum security plugin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20160302/5f234030/attachment-0001.sig>
On Wed, 2016-03-02 at 07:33 -0600, Johnny Hughes wrote:> Hopefully this makes sense. > > You can instead just look at this: > > https://lists.centos.org/pipermail/centos-announce/ > > (or subscribe to the CentOS announce mailing list to get emails) > > Both of those places will tell you when there is a security update. > > OR, you can subscribe to RHEL and use the information in the yum > security plugin. >Thanks for not sparing the gory details (and Alice and James) - much appreciated! I normally test my updates on non-critical systems before deploying to production. However, in this instance, I had been away from the office and wanted to quickly patch the openssl vulnerability before other non -critical/security related. In the end, I bit the bullet and just upgraded everything and no harm done. ak.
On Wed, March 2, 2016 5:24 am, Anthony K wrote:> On Tue, 2016-03-01 at 21:58 -0600, Johnny Hughes wrote: >> On 03/01/2016 09:41 PM, Johnny Hughes wrote: >> > BUt the security plugins do not work for CentOS and they never have, >> > Peter is correct, you need to run yum update or call out the specific >> > packages you want updated. >> > > > I totally understand the necessity of a full system update. However, this > begs > the question "Why code an option into yum that is of no use?"We are talking here CentOS and RHEL Linux. yum is an abbreviation of: "Yellowdog Update Manager". It was originally created by YellowDog Linux project for their Linux distribution. I don't know is they (YellowDog) actually using this particular feature or not, but RedHat (and hence CentOS) use features of yum they think fitting in their model. Incidentally, sometimes even when the project uses his own creature itself, they may end up abandoning some of the features that were originally coded in. Everyone who ever architectured some project himself, know that that often happens. Valeri> Was there a > time > when this option was functional? If yes, what caused its removal? Was it > a > system compromise at some big corporation and someone got sued/fired? > What? > Don't spare any gory details either! > > > ak. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
m.roth at 5-cent.us
2016-Mar-02 15:28 UTC
[CentOS] OpenSSL Update - not a security update???
One more voice on this: we actually run the yum security plugin, several
times a week, and it does report things... and almost all our systems are
CentOS.
When I see something in there, just as when I see an announcement where
there are updates marked important, and esp. critical, we roll them out,
by themselves if possible, within days, as opposed to waiting until the
maintenance window, which could be 3.5 weeks away.
We only do the full updates during the maintenance window (or via
negotiation with a workstation owner....)
mark
Once upon a time, Valeri Galtsev <galtsev at kicp.uchicago.edu> said:> We are talking here CentOS and RHEL Linux. yum is an abbreviation of: > "Yellowdog Update Manager". It was originally created by YellowDog Linux > project for their Linux distribution.Actually, yum is Yellowdog Updater, Modified. Seth Vidal (RIP) and others at Duke rewrote YUP (the Yellowdog UPdater) to handle Red Hat Linux. -- Chris Adams <linux at cmadams.net>
I understand that some people might be trying to cherry-pick their updates and the assertion that doing so is not supported. But that is not the only way in which --security can be used and it is a bit boring to continually see whining about the assumptive use. For me it is about scheduling -- it would answer the question: Does this system need updating immediately, vs scheduled for / deferred until a convenient time. I wish --security was functional and I do not accept that because it can be abused that it should therefore never be. That CentOS as yet has no way to make it functional is sad, and I hope that the lack is not due to the assumed use resulting in it being ignored. /mark
On 03/02/2016 10:42 AM, Mark Milhollan wrote:> I understand that some people might be trying to cherry-pick their > updates and the assertion that doing so is not supported. But that is > not the only way in which --security can be used and it is a bit boring > to continually see whining about the assumptive use. > > For me it is about scheduling -- it would answer the question: Does this > system need updating immediately, vs scheduled for / deferred until a > convenient time. > > I wish --security was functional and I do not accept that because it can > be abused that it should therefore never be. That CentOS as yet has no > way to make it functional is sad, and I hope that the lack is not due to > the assumed use resulting in it being ignored.That is not the reason, I have posted the reason several times .. including in this thread. We do not have enough space on donated mirrors and the data required for the xml file is not redistributable. It is not being ignored, it was designed to be used within rhn and since we give CentOS away for free, we can't buy the machines or bandwidth we need to include all rpms in all trees. Even if we could do that, we can't steal information and redistribute it if it is not licensed for such distribution. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20160302/0337a5c0/attachment-0001.sig>
Am 02.03.2016 um 17:42 schrieb Mark Milhollan <mlm at pixelgate.net>:> I understand that some people might be trying to cherry-pick their > updates and the assertion that doing so is not supported. But that is > not the only way in which --security can be used and it is a bit boring > to continually see whining about the assumptive use. > > For me it is about scheduling -- it would answer the question: Does this > system need updating immediately, vs scheduled for / deferred until a > convenient time. > > I wish --security was functional and I do not accept that because it can > be abused that it should therefore never be. That CentOS as yet has no > way to make it functional is sad, and I hope that the lack is not due to > the assumed use resulting in it being ignored.As it was said, "yum check-update/update" is the way to go (also for RHEL). We do not need here something like SCAP, therefore http://search.gmane.org/?query=CESA&group=gmane.linux.centos.announce&sort=date gives enough informations to schedule the security activities. -- LF