On 5/16/06, James Kosin <jkosin@xxxxxxxxxxxxxxxxxx> wrote:
-----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) A backport should be preferred over an outright upgrade in most circumstances. One example, we should not upgrade everyone to gcc-4.x just because upstream decides it fixes or performs better. This would break many things especially kernel trees. 2.4 kernels do not compile with 4.x of gcc and that group doing work on the 2.4 kernel have abandoned any support for 4.x of gcc.
I would say that there are core items of any release that are what define the release and thus shouldnt be majorly upgraded kernel <and corresponding module tools> gcc glibc python perl come immediately to mind. something like pine may not be upgraded in say RHL-7 because of license changes. However at some point, we may just have to say "We cant fix this and will have to EOL this product chain because this vulnerability is too big." I mean if RHL-6 was on the list of products to be supported.. I would say that we don't have the expertise to fix glibc issues in it.
(4) We need to be sure we are not opening everyone up for a bigger problem of some security issue in the future with the newer versions of software. One of Linux's claim to security is the diversity of applications out there and the many differences between all the different versions. Virus writers need a stable platform to do their craft. If we fall into Windows trap of providing a common platform we open up the virus world to the Linux community in large scale attack. Security updates are important, but we also need to have a way of safeguarding the current users against attacks while the solution is merged in in a timely manner and fully tested to fix the problem and proven not to break anything catastrophically.
This one is plain wrong. I address it because it used a lot and the quotes for truth are usually pointing to some mailing list where it was quoted before and no-one said otherwise. Malware writers need only a stable kernel ABI, and a stable libc ABI. The Linux malware I have seen works pretty much on any Linux platform because every distributor supplies a libc and a kernel that works with everyone else. The good ones work well in knowing the differences between say Apache-2.0 and Apache-1.3 and change tactics to deal with what is presented. The first reason that there are not large scale virus's for Linux is that it is a small percentage of the population and so doesn't have a good spreading mechanism (there is a difference if 2 machines on a network are chatty and 2000 machines). The second reason is that there isnt money in it for large scale virus attacks. It is more important to use small less noticable worms that create botmasters for windows farms or mine out data (credit cards, etc) from e-commerse sites.
-- Stephen J Smoogen. CSIRT/Linux System Administrator -- fedora-legacy-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
