Fedora products, to upgrade rather than backport?
So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what upstream does. Flames? Thoughts? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) signature.asc Description: This is a digitally signed message part -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
Quoting Jesse Keating [EMAIL PROTECTED]: So in the RHL space, the choice was clear. Backport whenever possible. True. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? Only because FL was originally do no harm type of philosophy, based on the idea that people would want stability, for example for servers. Now, one could argue that one shouldn't use FC for servers, and one shouldn't expect FC to be stable, and if so, one could say there is no reason to worry about backporting FC and that one should just upgrade packages. If we want to be transparent to end users we should follow what upstream does. Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. If you want to be transparent in the the sense of keeping with FC practices, then yes, you should upgrade instead of backporting. Flames? Thoughts? No flames, only thoughts, and not very deep thoughts at that. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On Mon, 15 May 2006, Jesse Keating wrote: So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what upstream does. My opinion here is: do whichever is the easiest. In some cases, doing a backport may be easier than upgrade [*]. One should also look at the approach chosen by other Fedora Core/RHEL releases. Other things being equal, prefer backporting. [*] For example: if you'd need to upgrade a package with a lot of dependencies which might need to be re-spun as well; or if the result would be a significant upgrade, getting assurance that the package would work, spec file updates required etc. could be significant work. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Keating wrote: So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what upstream does. Flames? Thoughts? - -1 to preferring upgrades. FL is about 'stability', which is an explicit non-goal for FC. Except in cases where a backport is more likely to create instability than an upgrade, we should prefer backporting. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEaNwf+gerLs4ltQ4RAi+HAKCS4ndoHA8hkicsUMwIwmZJH4t7dACfZzUp wGPYc9TXtwNXeTYu/G8/9L0= =K3Rd -END PGP SIGNATURE- -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On 5/15/06, Jesse Keating [EMAIL PROTECTED] wrote: So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what upstream does. I think that we should try and take some reasonable goals for timelines for security: What should our goal be for turn-around time be for a vulnerability? [Off the wall answers below.] Critical: 48 hours Moderate: 168 hours Low: 720 hours Second, how hard is it to backport? Hard: Code is no longer maintained and a quick patch attempt showed lots of collisions and rewrites. Moderate: Code is maintained, but code is different. Low: Patch was given for this version or code is only slightly different. Third, how expert are you (the patcher) on what the vulnerability is, what the code is, and how you are 'stopping' the vulnerability from being there. I think from those three, one could work out a decision tree on backporting or new release. In the case of new releases, we would make it part of the QA process to try and give a quick documentation of changes between old version and new version. Flames? Thoughts? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEaNR24v2HLvE71NURAlEtAJ4j6pIvTI7HWRbEbO08JM1DRdz4EgCcC8fj ZiIA6+ltESrc4RKxmK2298o= =2J1I -END PGP SIGNATURE- -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote: Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. When people intimately familiar with a given code, because they authored it, do not even attempt to provide security patches for older versions as internals were completely re-written and it is not even clear how to patch old holes, you expect that a small group of volunteers will do a deep analysis and come quickly with correct and safe patches for whatever? Such request is not even funny. In case you wonder the above was exactly the case with relatively recent updates to sendmail and is normally the case with mozilla (try to peek into that code and you will see why). What is more such leaf applications, as opposed to deeply intertwined libraries, are not a real problem - packaging hiccups notwithstanding. On one occasion I was replacing sendmail with a current version on a system with a provenience susbtantially earlier than whatever is supported by Legacy. It was not an issue. True, compile options had to be adjusted to what was available and a symlink or two was needed, and one had to be mildly careful with a configuration, but no real show stoppers. Not mentioning, of course, that if you know proven patches to old versions then you should not sit on that information. Michal -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On Mon, 2006-05-15 at 15:20 -0400, Jesse Keating wrote: So in the RHL space, the choice was clear. Backport whenever possible. However the Fedora landscape is different. Upstream Core does not do backporting, they more often than not version upgrade to resolve security issues. Why should Legacy be any different? If we want to be transparent to end users we should follow what upstream does. Every time we've decided to upgrade a package instead of backporting security fixes, we've broken other stuff and have had to work twice as hard to get things back into working order. I don't think we have the resources to upgrade packages. Backporting is a lot less work... Marc. signature.asc Description: This is a digitally signed message part -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
Quoting Stephen John Smoogen [EMAIL PROTECTED]: I think that we should try and take some reasonable goals for timelines for security: I don't think we have the man-power to set goals for all patches. But we should and do use the timeliness criterium for whether to backport or upgrade already. Second, how hard is it to backport? We alread consider this, though we have no defined process for doing so. Hard: Code is no longer maintained and a quick patch attempt showed lots of collisions and rewrites. Moderate: Code is maintained, but code is different. Low: Patch was given for this version or code is only slightly different. Seems reasonable, and is probably how we already would approach the situation even though it isn't really quantified. But, it also needs to look at the other side of the coin, that of upgrading: How hard would it be to upgrade rather than backport: Hard: Requires the non-trivial updating of other packages too (e.g. 2.4 kernel to 2.6 kernel requires too many other changes to be reasonable, same for LVM1 to LVM2, etc). Moderate: Requires a lot of work for the end-user (e.g. upgrade apache 1.x to apache 2.x requires configuration changes, may break many modules or require module upgrades, etc). Easy: Upgrading this package does not require any other packages to be upgraded (or if it does, they are also trivial/easy), doesn't require configuration files be manually upgraded, etc. Third, how expert are you (the patcher) on what the vulnerability is, what the code is, and how you are 'stopping' the vulnerability from being there. I'm not sure that should come into play per se. I think from those three, one could work out a decision tree on backporting or new release. In the case of new releases, we would make it part of the QA process to try and give a quick documentation of changes between old version and new version. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
Quoting Jesse Keating [EMAIL PROTECTED]: Sure, for RHL it is about stability. But with FC it was more about extending the lifespan. And to me, it really doesn't make sense to change the way in which the Fedora Project treats a release just because a different set of folks are touching it. You can though think it does make sense to change the handling because it is EOL, independent of who is touching it. EOL means end of development which means end of upgrades, at least to some. One question is what size of upgrades are you talking about. There's a big difference in going from kernel 2.4.12 to 2.4.13 versus going from 2.4.12 to 2.6.10 (just made up version numbers, but you get the idea). Same with going from apache 1.x.5 to 1.x.6 versus going from apache 1.x.5 to apache 2.x.y. If the upgrade doesn't require other non-trivial upgrades, doesn't require too many other upgrades, doesn't require manual reconfiguration, doesn't break the command line API, doesn't break the system, then I don't have a problem with an upgrade. If the upgrade does any of the above, then I have a problem. I'm trying to establish a scenario where the Fedora Project as a whole has a certain lifespan for a Fedora (core+extras) release. An end user really shouldn't care how the updates are generated, just that they are published and announced in the same spaces, and that the content of said updates. As long as they don't break more than they fix... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On 5/15/06, Eric Rostetter [EMAIL PROTECTED] wrote: Quoting Stephen John Smoogen [EMAIL PROTECTED]: Third, how expert are you (the patcher) on what the vulnerability is, what the code is, and how you are 'stopping' the vulnerability from being there. I'm not sure that should come into play per se. Does this explain it better? If you are not familiar with the code base and having to figure out a backpatch by hand (e.g. there is no available one for that release, etc), then how sure are you that you have fixed the security problem without opening another security problem? -- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
Quoting Michal Jaegermann [EMAIL PROTECTED]: On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote: Depends on what transparent means. If you want to be transparent in the sense of not breaking people's working machines, then no, you should backport. When people intimately familiar with a given code, because they authored it, do not even attempt to provide security patches for older versions as internals were completely re-written and it is not even clear how to patch old holes, you expect that a small group of volunteers will do a deep analysis and come quickly with correct and safe patches for whatever? Such request is not even funny. FL already has a policy, and it applies to RHL as well as FL. If the code can't reasonable be backported, we upgrade. End of discussion. In case you wonder the above was exactly the case with relatively recent updates to sendmail and is normally the case with mozilla (try to peek into that code and you will see why). Yea, and postgresql, etc. But this isn't the issue at hand. What is more such leaf applications, as opposed to deeply intertwined libraries, are not a real problem - packaging hiccups notwithstanding. They can be, like in the case of postgresql which requires you dump your DB, upgrade, restore the DB, or else you are SOL. And we already know how many people just set yum to do automatic updates and would be burned in such a case. Think about all the problems we would have if we upgraded from PHP 4.x to PHP 5.x. Man, that would be a nightmare for the users... Michal -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On 5/15/06, Eric Rostetter [EMAIL PROTECTED] wrote: Quoting Jesse Keating [EMAIL PROTECTED]: Sure, for RHL it is about stability. But with FC it was more about extending the lifespan. And to me, it really doesn't make sense to change the way in which the Fedora Project treats a release just because a different set of folks are touching it. I'm trying to establish a scenario where the Fedora Project as a whole has a certain lifespan for a Fedora (core+extras) release. An end user really shouldn't care how the updates are generated, just that they are published and announced in the same spaces, and that the content of said updates. As long as they don't break more than they fix... I think the problem with defining this is that the QA resources are even more limited than the developer resources. So a lot of problems do not get seen because we have a 3 'worksforme' and no For Cthulhu's sake, don't push this -- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
On Mon, 2006-05-15 at 16:12 -0500, Eric Rostetter wrote: You can though think it does make sense to change the handling because it is EOL, independent of who is touching it. EOL means end of development which means end of upgrades, at least to some. Can we agree to not use the term EOL in this way? I made a huge mistake in starting this trend. We really should be looking at 'EOL' as when _we_ stop touching it. It should be considered Maintenance Mode after Red Hat stops touching it. This line may blur if/when Core + Extras gets merged into one happy 'verse of packages maintained by a combination of external and internal folks, then the Maint Mode becomes a timeline issue not when RH stops touching it issue. Regardless, EOL shouldn't be until the Fedora Project in general stops touching it. One question is what size of upgrades are you talking about. There's a big difference in going from kernel 2.4.12 to 2.4.13 versus going from 2.4.12 to 2.6.10 (just made up version numbers, but you get the idea). Same with going from apache 1.x.5 to 1.x.6 versus going from apache 1.x.5 to apache 2.x.y. True, those would be insane. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) signature.asc Description: This is a digitally signed message part -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Legacy Test Update Notification: mozilla
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189137-1 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137 2006-05-15 - Name: mozilla Versions: rh7.3: mozilla-1.7.13-0.73.1.legacy Versions: rh9: mozilla-1.7.13-0.90.1.legacy Versions: fc1: mozilla-1.7.13-1.1.1.legacy Versions: fc2: mozilla-1.7.13-1.2.1.legacy Versions: fc3: mozilla-1.7.13-1.3.1.legacy Summary : A Web browser. Description : Mozilla is an open-source Web browser, designed for standards compliance, performance, and portability. - Update Information: Updated mozilla packages that fix several security bugs are now available. Mozilla is an open source Web browser, advanced email and newsgroup client, IRC chat client, and HTML editor. Several bugs were found in the way Mozilla processes malformed javascript. A malicious web page could modify the content of a different open web page, possibly stealing sensitive information or conducting a cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Mozilla processes certain javascript actions. A malicious web page could execute arbitrary javascript instructions with the permissions of chrome, allowing the page to steal sensitive information or install browser malware. (CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Mozilla processes malformed web pages. A carefully crafted malicious web page could cause the execution of arbitrary code as the user running Mozilla. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Mozilla displays the secure site icon. If a browser is configured to display the non-default secure site modal warning dialog, it may be possible to trick a user into believing they are viewing a secure site. (CVE-2006-1740) A bug was found in the way Mozilla allows javascript mutation events on input form elements. A malicious web page could be created in such a way that when a user submits a form, an arbitrary file could be uploaded to the attacker. (CVE-2006-1729) A bug was found in the way Mozilla executes in-line mail forwarding. If a user can be tricked into forwarding a maliciously crafted mail message as in-line content, it is possible for the message to execute javascript with the permissions of chrome. (CVE-2006-0884) Users of Mozilla are advised to upgrade to these updated packages containing Mozilla version 1.7.13 which corrects these issues. - Changelogs rh7.3: * Sat Apr 22 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-0.73.1.legacy - Updated to 1.7.13 to fix security issues rh9: * Sat Apr 22 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-0.90.1.legacy - Updated to 1.7.13 to fix security issues fc1: * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-1.1.1.legacy - Updated to 1.7.13 to fix security issues fc2: * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-1.2.1.legacy - Updated to 1.7.13 to fix security issues fc3: * Fri Apr 21 2006 Marc Deslauriers [EMAIL PROTECTED] 37:1.7.13-1.3.1.legacy - Updated to 1.7.13 to fix security issues - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh7.3: b7616c52ee2776f3577fcda0a0628c5ec6cffae7 redhat/7.3/updates-testing/i386/mozilla-1.7.13-0.73.1.legacy.i386.rpm a6234bd3b89616ce5b924a36c95ba1421b6b8ecf redhat/7.3/updates-testing/i386/mozilla-chat-1.7.13-0.73.1.legacy.i386.rpm 3d7b92d47b825f5a936c54ca63679916f428917e redhat/7.3/updates-testing/i386/mozilla-devel-1.7.13-0.73.1.legacy.i386.rpm 2b4c765543b3f4fc5ac04127ca70c70a33fddaec redhat/7.3/updates-testing/i386/mozilla-dom-inspector-1.7.13-0.73.1.legacy.i386.rpm c15eceb55105a87f8d5dc0db24b9cf95e815a5a2 redhat/7.3/updates-testing/i386/mozilla-js-debugger-1.7.13-0.73.1.legacy.i386.rpm 09dcdb176779a013efc6b1819e5391854d94a751 redhat/7.3/updates-testing/i386/mozilla-mail-1.7.13-0.73.1.legacy.i386.rpm 5126d56d8ff98dfdcd69ed6864821120fc959c55 redhat/7.3/updates-testing/i386/mozilla-nspr-1.7.13-0.73.1.legacy.i386.rpm d2db357f5fe0d1ffce22db18f7d95c96dcfcffa3 redhat/7.3/updates-testing/i386/mozilla-nspr-devel-1.7.13-0.73.1.legacy.i386.rpm 7b3a403f4981d5ffa676aa38e5699fca9e7c2f18 redhat/7.3/updates-testing/i386/mozilla-nss-1.7.13-0.73.1.legacy.i386.rpm 3eea1812fa6a6ef13ed8826cd7734bd266c9b0fb redhat/7.3/updates-testing/i386/mozilla-nss-devel-1.7.13-0.73.1.legacy.i386.rpm 46393b4afb72fcd8100de2c61b6531d9ffe1dbf5 redhat/7.3/updates-testing/i386/galeon-1.2.14-0.73.6.legacy.i386.rpm
Fedora Legacy Test Update Notification: firefox
- Fedora Legacy Test Update Notification FEDORALEGACY-2006-189137-2 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189137 2006-05-15 - Name: firefox Versions: fc3: firefox-1.0.8-1.1.fc3.1.legacy Summary : Mozilla Firefox Web browser. Description : Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. - Update Information: An updated firefox package that fixes several security bugs is now available. Mozilla Firefox is an open-source web browser, designed for standards compliance, performance and portability. Several bugs were found in the way Firefox processes malformed javascript. A malicious web page could modify the content of a different open web page, possibly stealing sensitive information or conducting a cross-site scripting attack. (CVE-2006-1731, CVE-2006-1732, CVE-2006-1741) Several bugs were found in the way Firefox processes certain javascript actions. A malicious web page could execute arbitrary javascript instructions with the permissions of chrome, allowing the page to steal sensitive information or install browser malware. (CVE-2006-1727, CVE-2006-1728, CVE-2006-1733, CVE-2006-1734, CVE-2006-1735, CVE-2006-1742) Several bugs were found in the way Firefox processes malformed web pages. A carefully crafted malicious web page could cause the execution of arbitrary code as the user running Firefox. (CVE-2006-0748, CVE-2006-0749, CVE-2006-1724, CVE-2006-1730, CVE-2006-1737, CVE-2006-1738, CVE-2006-1739, CVE-2006-1790) A bug was found in the way Firefox displays the secure site icon. If a browser is configured to display the non-default secure site modal warning dialog, it may be possible to trick a user into believing they are viewing a secure site. (CVE-2006-1740) A bug was found in the way Firefox allows javascript mutation events on input form elements. A malicious web page could be created in such a way that when a user submits a form, an arbitrary file could be uploaded to the attacker. (CVE-2006-1729) Users of Firefox are advised to upgrade to these updated packages containing Firefox version 1.0.8 which corrects these issues. - Changelogs fc3: * Wed Apr 19 2006 Marc Deslauriers [EMAIL PROTECTED] 0:1.0.8-1.1.fc3.1.legacy - Update to firefox 1.0.8 - This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) fc3: 8b719bb18c6dfe14b472c684ac5133d82d1b96d0 fedora/3/updates-testing/i386/firefox-1.0.8-1.1.fc3.1.legacy.i386.rpm 946f2ccbc412675ee6959a3dee50c2cb3ba90c3a fedora/3/updates-testing/x86_64/firefox-1.0.8-1.1.fc3.1.legacy.x86_64.rpm 0747aa65730e328a9274ec66c0de8dc30645dc1d fedora/3/updates-testing/SRPMS/firefox-1.0.8-1.1.fc3.1.legacy.src.rpm - Please test and comment in bugzilla. signature.asc Description: OpenPGP digital signature -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Fedora products, to upgrade rather than backport?
Quoting Michal Jaegermann [EMAIL PROTECTED]: I never tried to imply that automatic version chase is a good thing, and is definitely bad in case of libraries, but there are situations when you simply do not have a choice. Avoiding security updates because you do not want to change versions is in general not an option. Exactly what I'm am saying. Now we just need consensus on what situations call for which method. To me, the existing methods are fine. Jesse raised the question of should we change it. I answered him honestly and simply. Then I replied to a bunch of other post, in which I took an extreme position to the conservative side, for no other reason than to counter the many extreme positions to the liberal. Kind of Devil's Advocate if you will. I also think that for systems where you really want a long-term stable software base you should use nowadays distros like RHEL, or clones like CentOS, and for other pushing them far beyond EOL quickly becomes more trouble then it is worth. Then why not just end the FL project? But seriously, it isn't just pushing them far beyond EOL. It is pushing them just slightly beyond EOL in many cases. I don't care if FC3 is pushed for more than 6 months. I just want some time to schedule an upgrade, not an indefinate lifetime. Michal -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
