Quoting Stephen John Smoogen <smooge@xxxxxxxxx>:
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-legacy-list