fixing the vulnerability in linux-f10-pango-1.22.3_1

[Matthias Andree]

Am 13.02.2011 22:53, schrieb Tom Uffner:
> is there any point in trying to update linux-f10-pango to address this
> vulnerability?
> 
> Affected package: linux-f10-pango-1.22.3_1
> Type of problem: pango -- integer overflow.
> Reference:
> <http://portaudit.FreeBSD.org/4b172278-3f46-11de-becb-001cc0377035.html>
> 
> I realize that I can install it w/ DISABLE_VULNERABILITIES. but I hate
> having known exploits on my system & not installing it breaks flashplugin
> and acroread (among others).
> 
> I've never tried to create or modify a linux emulation port before; so I'm
> wondering just how annoying & tedious it's going to be?
> 
> it looks like there are no Fedora 10 RPMs of pango > 1.24 so it would
> probably involve finding an F10 box and building one from source.

Fedora 10 hasn't been supported for over a year now (EOL Mid December
2009), chances are, however, that newer versions of the system can build
an RPM that would fit F10.

There are online build services (for instance by/for openSUSE, starts
with Fedora 12 however), if you find a release that is close enough in
other shared library versions, that might help.

Backporting just a security fix, if a reliable and reasonable patch
exists, might be an easier option because you can take F10's 1.22.3
*source* RPM, add the security patch, and rebuild (see below).

> But would updating just Pango be possible? Or would it start the "RPM Hell"
> avalanche and require me to re-roll all of my linux ports?

If you build an updated port of a compatible pango version on F10, that
would likely be painless *unless* the new pango version has changed
requirements; building on a newer Fedora release might warrant checking
dependencies though, with "rpm -qp --requires" or similar, and paying
attention to library versions.  Sometimes, it's possible to (un)define C
preprocessor macros to avoid newer features; I used to build bogofilter
RPMs for older glibc releases that way a couple of years ago, but
there's no guarantee this works, and it's a tedious "read the source
Tom" task.

> Is it time for a complete upgrade of our Linux ports to Fedora 14? or some
> other distro that is easier to track & update?

It would be time, but new distros always raise the question is the
kernel part of the linuxulator up to the job?  If [e]glibc or other
libraries require newer Linux kernel features not provided by the
FreeBSD linuxulator, that is a hard dependency to be fixed before.

Personally I'd prefer "some other distro that is easier to track &
update", particularly something with long-term support by the respective
vendor, so candidates are CentOS (closer to Fedora, also RPM-based, lags
a bit behind but is more or less a free spin of Red Hat Enterprise
Linux), Ubuntu LTS (3 years for desktop stuff), or possibly Debian. The
latter two use .dpkg as the packaging format, which is apparently ar based.

I don't have the time to get involved here though, beyond answering an
occasional Linux question.

HTH

-- 
Matthias Andree