On 5/15/06, Jesse Keating <jkeating@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
-- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-legacy-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
