Fedora products, to upgrade rather than backport?

[Stephen John Smoogen]

On 5/16/06, James Kosin <jkosin at beta.intcomgrp.com> 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