Hello,
Since Shellshock I have looked at using automated updates via yum-cron, but I only want them in case of critical issues. I expected that yum-plugin-security would at least update bash when this command was used: yum --security update-minimal
Does this work on RHEL only?
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
On 29/09/14 14:02, Nux! wrote:
Hello,
Since Shellshock I have looked at using automated updates via yum-cron, but I only want them in case of critical issues. I expected that yum-plugin-security would at least update bash when this command was used: yum --security update-minimal
Does this work on RHEL only?
yum-plugin-security is still a no-op on CentOS base repos as it always has been. It works for EPEL not for base/updates.
T
Thanks Trevor, I was afraid of this. :-)
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Trevor Hemsley" trevor.hemsley@ntlworld.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Monday, 29 September, 2014 14:15:29 Subject: Re: [CentOS-devel] yum-plugin-security and shellshock
On 29/09/14 14:02, Nux! wrote:
Hello,
Since Shellshock I have looked at using automated updates via yum-cron, but I only want them in case of critical issues. I expected that yum-plugin-security would at least update bash when this command was used: yum --security update-minimal
Does this work on RHEL only?
yum-plugin-security is still a no-op on CentOS base repos as it always has been. It works for EPEL not for base/updates.
T _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
This stops being a no-op if we get working updateinfo.xml into the CentOS repos.
On 09/29/2014 08:22 AM, Nux! wrote:
Thanks Trevor, I was afraid of this. :-)
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Trevor Hemsley" trevor.hemsley@ntlworld.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Monday, 29 September, 2014 14:15:29 Subject: Re: [CentOS-devel] yum-plugin-security and shellshock
On 29/09/14 14:02, Nux! wrote:
Hello,
Since Shellshock I have looked at using automated updates via yum-cron, but I only want them in case of critical issues. I expected that yum-plugin-security would at least update bash when this command was used: yum --security update-minimal
Does this work on RHEL only?
yum-plugin-security is still a no-op on CentOS base repos as it always has been. It works for EPEL not for base/updates.
T _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
What needs to happen for that?
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Kevin Stange" kevin@steadfast.net To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Tuesday, 30 September, 2014 02:33:49 Subject: Re: [CentOS-devel] yum-plugin-security and shellshock
This stops being a no-op if we get working updateinfo.xml into the CentOS repos.
On 09/29/2014 08:22 AM, Nux! wrote:
Thanks Trevor, I was afraid of this. :-)
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Trevor Hemsley" trevor.hemsley@ntlworld.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Monday, 29 September, 2014 14:15:29 Subject: Re: [CentOS-devel] yum-plugin-security and shellshock
On 29/09/14 14:02, Nux! wrote:
Hello,
Since Shellshock I have looked at using automated updates via yum-cron, but I only want them in case of critical issues. I expected that yum-plugin-security would at least update bash when this command was used: yum --security update-minimal
Does this work on RHEL only?
yum-plugin-security is still a no-op on CentOS base repos as it always has been. It works for EPEL not for base/updates.
T _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Kevin Stange Chief Technology Officer Steadfast | http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
All the SL tools are published at: https://cdcvs.fnal.gov/redmine/projects/python-updateinfo
Pat
Very nice, Pat, thanks. Is there anything stopping the CentOS devs using this?
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Pat Riehecky" riehecky@fnal.gov To: centos-devel@centos.org Sent: Tuesday, 30 September, 2014 17:28:44 Subject: yum-plugin-security and shellshock
On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
All the SL tools are published at: https://cdcvs.fnal.gov/redmine/projects/python-updateinfo
Pat
-- Pat Riehecky
Scientific Linux developer http://www.scientificlinux.org/
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
The code is GPL, and should be compat with python 2.6 to python 3.3 and able to be packaged as a software collection.
Python 2.4 compat can be achieved by reducing the python 3 support.
Pat
On 09/30/2014 11:52 AM, Nux! wrote:
Very nice, Pat, thanks. Is there anything stopping the CentOS devs using this?
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Pat Riehecky" riehecky@fnal.gov To: centos-devel@centos.org Sent: Tuesday, 30 September, 2014 17:28:44 Subject: yum-plugin-security and shellshock On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
All the SL tools are published at: https://cdcvs.fnal.gov/redmine/projects/python-updateinfo
Pat
-- Pat Riehecky
Scientific Linux developer http://www.scientificlinux.org/
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
I think that is only one issue.
The other issue (as I understand it), is that we would need an all encompassing metadata across all versions to make this work as well.
Meaning that (lets take CentOS-6 as an example) ... we would need a tree of all RPMs (6.0, 6.1, 6.2, 6.3, 6.4, 6.5 .. plus all the updates directories) on all the mirrors to make that work.
I suppose we could do it if all the metadata was in one place (at a level up) and the directories could be separate.
But either way, it would add significantly to the size required to mirror CentOS and require a redesign of how we do trees completely (we currently only push the latest tree for each live major version).
(For example, we would likely have to separate ISOs out of main trees as there is no way we could mirror all the ISO's as well as all the binary RPMs for 11 CentOS 5 versions, 5 CentOS 6 versions, etc. to every mirror, that is several TB of info if we include ISOs)
=====================================================================
So, all of this would be required and the end result would be that you would then be able to install security updates only.
The only problem with that is ... in a staged build system, security updates only is not supported. It is not really supported in RHEL either. Why do I say that? Look at any RHEL RHSA update .. I'll take one of the shellshock updates:
https://rhn.redhat.com/errata/RHSA-2014-1306.html
If you look at the Solution section you will see this quote:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
It does not say all "previously release Security Errata" has been applied ... it does not say all "BugFix and Security Errata" has been applied .. it says "all previously released Errata" has been applied.
Why is that?
Well, because things are built on top of the last update (the build root used is 'staged'). The build root grows as you add packages to the distribution. Package A is built, it goes into the build root and then Package B gets built the next day against that Package A. If you run that Package B against an older version of Package A than the one it was built against, then it may not work the same way as it was intended to work.
So, the only 'supported' and 'tested' configuration is all the latest packages installed.
That is why Red Hat specifically has EUS/AUS repositories where they SPECIFICALLY built the same bash (in our example) against the extended 6.4 EUS tree. They have a different shell shock patched build of bash there:
https://rhn.redhat.com/errata/RHSA-2014-1311.html
The bash for RHEL-6.4 AUS is (after being built against the 6.4 AUS tree) different that the one for RHEL-6.5 .. why is that? Because it is the same source code, but it is built against a different subset of packages. (The AUS is basically all of 6.4 as it was when 6.5 was released, and all the new 6.5 security updates, built in order and in a staged manner against that 6.4 tree ... so it is '6.4 plus 6.5 security updates'.) Do you think Red Hat would maintain a separate AUS/EUS 6.4 tree and build all the new security updates from 6.5 again against that 6.4 EUS/AUS tree if the users could just not update to 6.5 and just use yum-security to use the 6.5 updates? Of course not, they would just use the 6.5 security packages for 6.4. They don't use the 6.5 security updates directly against 6.4, because it might not work. Instead, they maintain a separate 6.4 tree.
If you take the 6.5 bash update and install it in 6.4, will it work? Likely. Will it absolutely fix the security issue? Maybe not .. it is certainly not 'supported' by Red Hat that way.
======================================================================
So, only installing Security updates and not all updates is not a very good idea (certainly on on different minor versions), because you are not operating in a tested manner and the update could very well not even mitigate the security issue UNLESS you install all updates (security and otherwise) that happen before it anyway.
Therefore why would we want to take great pains to totally redesign our mirror infrastructure (the size increase rendering some number of our current donated mirrors as too small to now be used). Take great pains to maintain a separate database of Security info to generate the xml file. Then that will make the end release that it is now very easy for users to think they are safe (because they do all security updates after all) ... but they are not safe because they are running 6.5 security updates against 6.4? Or help them run only critical security updates and the combination introduces new issues unique to that combination?
They only way to have another secure combination is to build and test the security updates in that combination. If you want 6.3 with only the 6.4 and 6.5 Moderate Security updates (or above) added to that, you would need to build the 6.4 and 6.5 security updates (in order) against that 6.3 tree ... staging it as you go so that the next update gets built against the update before it. You would also then need to TEST that this combination actually fixes the security issues. Then you could be reasonably sure that the solution was safe.
But if you just installed the CentOS 6.4 and 6.5 moderate updates (or higher) on CentOS 6.3 (the same packages you rebuilt in the preceding paragraph) .. even if they installed, it would be significantly different than the solution where you built them yourself.
Thanks Johnny for taking the time, it looks like the issue is much more convoluted than I initially assumed.
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Johnny Hughes" johnny@centos.org To: centos-devel@centos.org Sent: Wednesday, 1 October, 2014 10:00:04 Subject: Re: [CentOS-devel] yum-plugin-security and shellshock
On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
I think that is only one issue.
The other issue (as I understand it), is that we would need an all encompassing metadata across all versions to make this work as well.
Meaning that (lets take CentOS-6 as an example) ... we would need a tree of all RPMs (6.0, 6.1, 6.2, 6.3, 6.4, 6.5 .. plus all the updates directories) on all the mirrors to make that work.
I suppose we could do it if all the metadata was in one place (at a level up) and the directories could be separate.
But either way, it would add significantly to the size required to mirror CentOS and require a redesign of how we do trees completely (we currently only push the latest tree for each live major version).
(For example, we would likely have to separate ISOs out of main trees as there is no way we could mirror all the ISO's as well as all the binary RPMs for 11 CentOS 5 versions, 5 CentOS 6 versions, etc. to every mirror, that is several TB of info if we include ISOs)
=====================================================================
So, all of this would be required and the end result would be that you would then be able to install security updates only.
The only problem with that is ... in a staged build system, security updates only is not supported. It is not really supported in RHEL either. Why do I say that? Look at any RHEL RHSA update .. I'll take one of the shellshock updates:
https://rhn.redhat.com/errata/RHSA-2014-1306.html
If you look at the Solution section you will see this quote:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
It does not say all "previously release Security Errata" has been applied ... it does not say all "BugFix and Security Errata" has been applied .. it says "all previously released Errata" has been applied.
Why is that?
Well, because things are built on top of the last update (the build root used is 'staged'). The build root grows as you add packages to the distribution. Package A is built, it goes into the build root and then Package B gets built the next day against that Package A. If you run that Package B against an older version of Package A than the one it was built against, then it may not work the same way as it was intended to work.
So, the only 'supported' and 'tested' configuration is all the latest packages installed.
That is why Red Hat specifically has EUS/AUS repositories where they SPECIFICALLY built the same bash (in our example) against the extended 6.4 EUS tree. They have a different shell shock patched build of bash there:
https://rhn.redhat.com/errata/RHSA-2014-1311.html
The bash for RHEL-6.4 AUS is (after being built against the 6.4 AUS tree) different that the one for RHEL-6.5 .. why is that? Because it is the same source code, but it is built against a different subset of packages. (The AUS is basically all of 6.4 as it was when 6.5 was released, and all the new 6.5 security updates, built in order and in a staged manner against that 6.4 tree ... so it is '6.4 plus 6.5 security updates'.) Do you think Red Hat would maintain a separate AUS/EUS 6.4 tree and build all the new security updates from 6.5 again against that 6.4 EUS/AUS tree if the users could just not update to 6.5 and just use yum-security to use the 6.5 updates? Of course not, they would just use the 6.5 security packages for 6.4. They don't use the 6.5 security updates directly against 6.4, because it might not work. Instead, they maintain a separate 6.4 tree.
If you take the 6.5 bash update and install it in 6.4, will it work? Likely. Will it absolutely fix the security issue? Maybe not .. it is certainly not 'supported' by Red Hat that way.
======================================================================
So, only installing Security updates and not all updates is not a very good idea (certainly on on different minor versions), because you are not operating in a tested manner and the update could very well not even mitigate the security issue UNLESS you install all updates (security and otherwise) that happen before it anyway.
Therefore why would we want to take great pains to totally redesign our mirror infrastructure (the size increase rendering some number of our current donated mirrors as too small to now be used). Take great pains to maintain a separate database of Security info to generate the xml file. Then that will make the end release that it is now very easy for users to think they are safe (because they do all security updates after all) ... but they are not safe because they are running 6.5 security updates against 6.4? Or help them run only critical security updates and the combination introduces new issues unique to that combination?
They only way to have another secure combination is to build and test the security updates in that combination. If you want 6.3 with only the 6.4 and 6.5 Moderate Security updates (or above) added to that, you would need to build the 6.4 and 6.5 security updates (in order) against that 6.3 tree ... staging it as you go so that the next update gets built against the update before it. You would also then need to TEST that this combination actually fixes the security issues. Then you could be reasonably sure that the solution was safe.
But if you just installed the CentOS 6.4 and 6.5 moderate updates (or higher) on CentOS 6.3 (the same packages you rebuilt in the preceding paragraph) .. even if they installed, it would be significantly different than the solution where you built them yourself.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2014 04:00 AM, Johnny Hughes wrote:
On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
I think that is only one issue.
All of these excuses below are FUD.
The other issue (as I understand it), is that we would need an all encompassing metadata across all versions to make this work as well.
Just worry about what's on the mirror today and when a new package is released, update the metadata for that one.
Why would you need metadata for packages that go back to before the current release? These updates are no longer available and new installations are going to start at the current base. You certainly could match all the current in-tree packages to an errata release if applicable and keep them in an updateinfo.xml in base.
As you go, keep all the advisories in a database of some kind, with all the required data, such as ID number, package files, link to RHEL errata, type of fix. Then just generate the updateinfo.xml for all applicable packages in the current repos (base AND updates) and leave unknown packages out.
If you do that, then as time goes on, the errata coverage will fill in over the life of the distribution. For a while, only updates to the most recent release(s) will be covered, which is going to be the bulk of what people are installing anyway. If you never start tracking this information, you are staking a committment to ensuring there's never any of this data, which doesn't make any sense.
If someone's installing a package for the first time, the errata isn't really important. It's only important when someone's looking to install an updated version of something they already have.
In the case of Spacewalk, you start with the packages on the current distro version and relevant errata. As it updates packages, it keeps the errata associations even if the package later moves from 5.10/updates to 5.11/base. It also keeps all older packages in the system, so that's not a burden that has to be placed on mirrors.
If someone really wants their spacewalk full of all packages ever released for a distro, they can seed it back from the vault, but I doubt very much that's something most people are looking for.
So, all of this would be required and the end result would be that you would then be able to install security updates only.
<snip>
If you take the 6.5 bash update and install it in 6.4, will it work? Likely. Will it absolutely fix the security issue? Maybe not .. it is certainly not 'supported' by Red Hat that way.
Well, in the bash case, yes, this update is self-contained and it will fix the issue for any version of CentOS you install it on (that can run it). RH doesn't support that officially, but it'll be fine.
I know of ONE instance of cherry-picking a security update released by CentOS that didn't work fine when all its dependencies were otherwise met in the history of using CentOS. It was an OpenSSL update that broke compatibility if you didn't also update other packages, and it was several years ago, in CentOS 4.
Your argument is beside the point though. Even if cherry-picking is not the recommended way to patch, the information doesn't have its sole benefit in allowing people to do that. With the right tools (increasingly becoming default tools), users see classification of packages and can more easily discover the errata without having to be subscribed to centos-announce.
If you use the graphical updater in Fedora, you get a list of all packages that have updates available matched with types of updates. Fedora recommends installing them all, but it also triggers additional urgency when one or more are security related. It even triggers reboot/logout recommendations if those are noted by the update info. The yum plugin also lists the type of fixes when you run yum update, so you can see the importance of doing an update ASAP.
Therefore why would we want to take great pains to totally redesign our mirror infrastructure (the size increase rendering some number of our current donated mirrors as too small to now be used). Take great pains to maintain a separate database of Security info to generate the xml file. Then that will make the end release that it is now very easy for users to think they are safe (because they do all security updates after all) ... but they are not safe because they are running 6.5 security updates against 6.4? Or help them run only critical security updates and the combination introduces new issues unique to that combination?
You don't have to do this. Doing this would be a pain in the ass and cause tons of problems for no reason. This ask is for ONE TINY XML FILE per repo. That's all. And it's probably not necessary for anything but base and updates/ though I would recommend it for any repo that is ever changed throughout a release lifecycle.
updateinfo.xml for base would be statically generated at initial release with the errata known to map to current versions of packages being shipped from previous releases of CentOS. If this coverage starts out at only a handful of packages, it's better than nothing. If this is really impossibly hard to do, then skip and just do updates/ to start out. Right now the only way is scraping the mailing list to get this old data, but it's there for the taking.
They only way to have another secure combination is to build and test the security updates in that combination. If you want 6.3 with only the 6.4 and 6.5 Moderate Security updates (or above) added to that, you would need to build the 6.4 and 6.5 security updates (in order) against that 6.3 tree ... staging it as you go so that the next update gets built against the update before it. You would also then need to TEST that this combination actually fixes the security issues. Then you could be reasonably sure that the solution was safe.
But if you just installed the CentOS 6.4 and 6.5 moderate updates (or higher) on CentOS 6.3 (the same packages you rebuilt in the preceding paragraph) .. even if they installed, it would be significantly different than the solution where you built them yourself.
I don't think anyone has asked for this. No one expects this in Fedora or SL. All I want is the metadata in the repo for the CURRENT packages that are in the repo, so that when I import then into spacewalk or run "yum update" I can easily pull up the information about those packages.
If an update occasionally is missing, it's not the end of the world. Even 50% coverage is better than the 0% we have now, but getting 100% of current updates/ repos and future releases is as simple as being willing to just start storing the information and making generating the file part of your release process.
SL has managed to figure out how to do this without mirrors having every file ever released. I'm sure CentOS has the ability to do so.
- -- Kevin Stange Chief Technology Officer Steadfast | http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688
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?
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?
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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
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.
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.
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.
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.
- -- Kevin Stange Chief Technology Officer Steadfast | http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688
-----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 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
On 10/01/2014 10:07 PM, Kevin Stange wrote:
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?
Fedora is a complete enclosed distro - their proposition is different. For SL - they publish the metadata and hope for the best, maybe that is fine with their userbase but winging it and keeping fingers crossed is really not how I'd want to run my systems.
While there is still a firewall between us and the RHEL QE / RelEngg ; but based on the conversations we've had and what I've seen happening - its pretty clear the the SL guys are pushing confidence around things that they need to own - and as far as I can tell there is no effort to actually validate any of it; even to the point that when heartbleed happened - I had to go remind them that every SL version and every user instance was exploiteable; unlike RHEL and CentOS where only folks who had updated in the few weeks leading upto the issue being reported.
If you want to see this issue resolved, then blindly throwing something over the wall and hoping for the best isnt the way to do it - there are fairly tangiable pieces of work that need to be done, find the time, do the work. We can all gain from it.
Besides, if its a case of winging it, why not wing it with a 'yum update *' - atleast you are then winging it with a tested process ( upstream and to -some- extent in centos.org too ).
On 10/02/2014 03:39 AM, Karanbir Singh wrote:
On 10/01/2014 10:07 PM, Kevin Stange wrote:
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?
Fedora is a complete enclosed distro - their proposition is different. For SL - they publish the metadata and hope for the best, maybe that is fine with their userbase but winging it and keeping fingers crossed is really not how I'd want to run my systems.
While there is still a firewall between us and the RHEL QE / RelEngg ; but based on the conversations we've had and what I've seen happening - its pretty clear the the SL guys are pushing confidence around things that they need to own - and as far as I can tell there is no effort to actually validate any of it; even to the point that when heartbleed happened - I had to go remind them that every SL version and every user instance was exploiteable; unlike RHEL and CentOS where only folks who had updated in the few weeks leading upto the issue being reported.
If you want to see this issue resolved, then blindly throwing something over the wall and hoping for the best isnt the way to do it - there are fairly tangiable pieces of work that need to be done, find the time, do the work. We can all gain from it.
Besides, if its a case of winging it, why not wing it with a 'yum update *' - atleast you are then winging it with a tested process ( upstream and to -some- extent in centos.org too ).
I don't do a yum update *, I review all update notes, and I update the trivial packages in one pass and a separate pass for each component that I believe might cause a system problem.
I would like to help add updateinfo.xml but I don't have a connection to the release process where I understand *how* I can inject this behavior. Where can I store the errata metadata during the release so that it's able to be persistently available for regenerating the current version of updateinfo.xml?
I'm asking to make an actual change to your update release process, so if you guys are fighting with me about the very idea of even having this information, I feel like there's very little chance you would actually be willing to integrate the new steps. If I haven't got any reasonable agreement that this is a good thing first, then any effort I put in is arguably pointless.
I might as well keep my ugly mailing list scraping hack, even though it doesn't always work right, because it's better than a lot of effort that never gets off the ground.
I am willing to make the effort but the release process is still somewhat opaque to me, and I need some buy in from people releasing the updates if this is actually something we can realize.
On Thu, Oct 2, 2014 at 3:39 AM, Karanbir Singh mail-lists@karan.org wrote:
Besides, if its a case of winging it, why not wing it with a 'yum update *' - atleast you are then winging it with a tested process ( upstream and to -some- extent in centos.org too ).
Please reconsider that statement for the scenario where the bulk of the code running on the server is 3rd party and locally developed. Your recommendation throws together a vast number of changes that are not tested together with the applications that are the reason for running the machine, and most of which are not at all necessary. But once a vulnerability has been made public, you really have no choice but to fix that specific thing.
On 10/02/2014 03:39 AM, Karanbir Singh wrote:
even to the point that when heartbleed happened - I had to go remind them that every SL version and every user instance was exploiteable; unlike RHEL and CentOS where only folks who had updated in the few weeks leading upto the issue being reported.
There were about 12 weeks between the publication of SA-2014:0015 (January) and SA-2014:0376 (April) by RedHat, CentOS and SL.
Your notification was considerate, but did not provide any new information. We had already published the SA-2014:0376 update for all SL 6 releases and notified our userbase.
Per our publication practices, we published the SA-2014:0015 (security classification Important) for all SL6 releases. It protected against the following CVEs: CVE-2013-6449 CVE-2013-6450 CVE-2013-4353
Similarly, we published SA-2014:0376 (security classification Important) for all SL6 releases. It protected against the following CVE: CVE-2014-0160 (heartbleed)
OpenSSL packages published before SA-2014:0015 contain CVE-2013-6449 CVE-2013-6450. BA-2013:1585-1 contains CVE-2013-4353. OpenSSL packages published after BA-2013:1585-1 and before SA-2014:0376 contain CVE-2014-0160.
We were fully aware of which versions of openssl contained CVE-2014-0160 and which SL versions contained the vulnerability.
Pat
On 10/02/2014 06:00 PM, Pat Riehecky wrote:
We were fully aware of which versions of openssl contained CVE-2014-0160 and which SL versions contained the vulnerability.
excellent, but you completely missed the point where all of SL installs were potentially at risk, with no way to factor back or check any state since there is no CVE validation being done.
or are you doing cve validations and testing expoits actively now ?
On 10/02/2014 12:31 PM, Karanbir Singh wrote:
On 10/02/2014 06:00 PM, Pat Riehecky wrote:
We were fully aware of which versions of openssl contained CVE-2014-0160 and which SL versions contained the vulnerability.
excellent, but you completely missed the point where all of SL installs were potentially at risk, with no way to factor back or check any state since there is no CVE validation being done.
or are you doing cve validations and testing expoits actively now ?
The CentOS Devel list seems to be the incorrect place to debate SL update policies.
SLSA-2014:0376 was verified to fix CVE-2014-0160 on SL 6.0, 6.1, 6.2, 6.3, 6.4, and 6.5 for both i686 and x86_64.
Without SLSA-2014:0015, SL 6.0, 6.1, 6.2, 6.3, and 6.4 systems are vulnerable to CVE-2013-6449 CVE-2013-6450.
Pat
On Thu, Oct 2, 2014 at 1:28 PM, Pat Riehecky riehecky@fnal.gov wrote:
On 10/02/2014 12:31 PM, Karanbir Singh wrote:
On 10/02/2014 06:00 PM, Pat Riehecky wrote:
We were fully aware of which versions of openssl contained CVE-2014-0160 and which SL versions contained the vulnerability.
excellent, but you completely missed the point where all of SL installs were potentially at risk, with no way to factor back or check any state since there is no CVE validation being done.
or are you doing cve validations and testing expoits actively now ?
The CentOS Devel list seems to be the incorrect place to debate SL update policies.
If you look at in the context of improving the systems and which serves the users needs best, then the more information the better. Do you have some examples of things that have broken on full minor-rev updates?
On Thu, Oct 2, 2014 at 3:00 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Thu, Oct 2, 2014 at 1:28 PM, Pat Riehecky riehecky@fnal.gov wrote:
On 10/02/2014 12:31 PM, Karanbir Singh wrote:
On 10/02/2014 06:00 PM, Pat Riehecky wrote:
We were fully aware of which versions of openssl contained CVE-2014-0160 and which SL versions contained the vulnerability.
excellent, but you completely missed the point where all of SL installs were potentially at risk, with no way to factor back or check any state since there is no CVE validation being done.
or are you doing cve validations and testing expoits actively now ?
The CentOS Devel list seems to be the incorrect place to debate SL update policies.
If you look at in the context of improving the systems and which serves the users needs best, then the more information the better. Do you have some examples of things that have broken on full minor-rev updates?
I personally work extensively with both. The underlying distinction is that the CentOS takes its old releases effectively offline, transferring them to the 'CentOS-Vault' repository where access to the out of date material requires additional steps. As such, it's vulnerable to some though not all of the "only update these components" issues. The lack of default access after a new minor release, such as CentOS 6.1 being in the vault by the time CentOS 6.5 was published, means that installations of one update such as openssl may trigger a host of other unexpected updates. The same is true for package installations without enabling the "CentOS-Vault". If I install openjdk later on on a CentOS 6.1 system, I get the CentOS 6.5 published openjdk. And I don't necessarily *want* to automatically get the latest revision with all its dependencies, I may want the same version as was available when I installed the system. It's workable as is, but takes some extra steps.
Worse: If I do "yum list extras" on a locked down CentOS system, one that has not been updated frequently, I get an enormous list of "extras" that are not accessible in the now active repositories. It gets quite confusing if you'e not paid attention to the layouts and update practices and needs to enable 'CentOS-Vault'. This can be chaotic for system consistency, and I'm personally dealing with some aspects of this right now.
The Scientific Linux layout segregates the "deployed OS" and keeps it available in the active yum mirrors, as "6.1", "6.2", etc. "Updates" seem to be locked, after an OS minor revision is update, at the state when the next minor revision occurred. The leading edge *is* available, in the "6x" repository, for those who elect to remain bleeding edge. And it can be enabled on a case by case basis. This is much closer to how Red Hat used to publish minor releases, with the exception that now there is always a "5x", "6x", "7x", etc. link to the latest minor release.
This makes keeping an internal mirror of the current and previous minor releases much easier, and it's not that much of a loss in repository efficiency as long as 'rsync' is used with the '-a --delete -H' options, with '-H' preserving hardlinks. It also makes updating to the full new release easier: I can do "yum install yum-conf-6x" to enable access to the current repo, and "yum delete yum-conf-6x" to lock it back down to the installed release.
I'm not judging either as the only way to do things: I'll admit that I've found Scientific Linux's approach to be helpful for full "bill-of-materials" stability.
On 10/02/2014 07:28 PM, Pat Riehecky wrote:
The CentOS Devel list seems to be the incorrect place to debate SL update policies.
you are right, dropping conversation.
- KB
On 10/01/2014 08:41 PM, Kevin Stange wrote:
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.
but your usecase does not represent a sane interface from the project side - hacking up something that is going to put users at risk is far worse that communicating that users need to really just apply all updates.
I really dont understand the corner case arguments you make here, Kevin you are far smarter than this. Are you just trying to tick a box off and dont care if that leaves a majority of the userbase exposed by incorrectly commnunicated confidence ?
The fact that you are actually looking to penalise people who dont run updates nightly is very dangerious.
On 10/02/2014 03:32 AM, Karanbir Singh wrote:
On 10/01/2014 08:41 PM, Kevin Stange wrote:
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.
but your usecase does not represent a sane interface from the project side - hacking up something that is going to put users at risk is far worse that communicating that users need to really just apply all updates.
I really dont understand the corner case arguments you make here, Kevin you are far smarter than this. Are you just trying to tick a box off and dont care if that leaves a majority of the userbase exposed by incorrectly commnunicated confidence ?
The fact that you are actually looking to penalise people who dont run updates nightly is very dangerious.
I'm not trying to penalize users who don't run updates nightly. I'm considering people who don't update at all for entire distro release cycles already doing things so badly, it barely matters if they're misinformed.
The point of this updateinfo.xml is to get information to people who are updating on an ongoing basis so they can see what kind of updates they're getting when they run their daily, weekly, or monthly yum update.
When I update my Windows servers, I read the update notices to see what component is being updated and why. I don't usually skip updates, but it lets me determine if maybe there are any things I should double check after applying or if I should delay an update while I need to QA something. I do the same thing in CentOS, but in CentOS the only source of information for this is the mailing list. It could appear right in the Update Manager, or at least the update manager could end up having a link right to the RHXAs.
I think there is an actual benefit for the people who update regularly that trumps people who choose to do really weird things and intentionally disregard the constant update process of the OS.
On 10/02/2014 03:37 PM, Kevin Stange wrote:
I'm not trying to penalize users who don't run updates nightly. I'm considering people who don't update at all for entire distro release cycles already doing things so badly, it barely matters if they're misinformed.
but in your regime - only if you are updating nightly are you going to have any level of confidence that you are not missing Security updates, specially around point release times, you are going to have times when complete tree's and the metadata around it goes away.
On Wed, Oct 1, 2014 at 2:10 PM, Johnny Hughes johnny@centos.org 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?
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?
This happened to me about two months ago. I had to manually enable CentOS-Vault repo access.
On Wed, Oct 1, 2014 at 4:00 AM, Johnny Hughes johnny@centos.org wrote:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
It does not say all "previously release Security Errata" has been applied ... it does not say all "BugFix and Security Errata" has been applied .. it says "all previously released Errata" has been applied.
Why is that?
Well, because things are built on top of the last update (the build root used is 'staged'). The build root grows as you add packages to the distribution. Package A is built, it goes into the build root and then Package B gets built the next day against that Package A. If you run that Package B against an older version of Package A than the one it was built against, then it may not work the same way as it was intended to work.
But, you have to consider it a bug against the 'stable API' concept of an enterprise distribution release if that api is broken, whether is it for user, third-party, or internal code.
If you take the 6.5 bash update and install it in 6.4, will it work? Likely. Will it absolutely fix the security issue? Maybe not .. it is certainly not 'supported' by Red Hat that way.
You've done a good job of describing the theory here. Now what about the practice on the consuming side? When you know you have an installed package with a known security vulnerability do you (a) ignore it, (b) install the one fixed package that hasn't been tested with the others, or (c) install a whole bunch of new code that hasn't been tested together with your third party and local packages?
Or should we maintain our own build environment matching current installations and rebuild source rpms individually as updates for them? None of these are going to be ideal, but neither is waiting to complete full-blown testing of a complex system before fixing a security issue. Just looking for expert opinions on the risks...
-
Jim Perrin -
Johnny Hughes -
Karanbir Singh -
Kevin Stange -
Les Mikesell -
Nico Kadel-Garcia -
Nux! -
Pat Riehecky -
Trevor Hemsley