-----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/security/repodata/updateinfo.xml >> > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQsNcYACgkQkd/BoeKjg0gF2gCfZxjeXO1aWDC9cLPGAYuUgjSI y9sAn0HTBvy9B6yyfxyX0xfdKSMMT96o =YMew -----END PGP SIGNATURE-----