Date: Mon, 14 Feb 2011 02:10:07 +0100 From: Matthias Andree <matthias.andree@gmx.de> To: freebsd-ports@freebsd.org Subject: Re: fixing the vulnerability in linux-f10-pango-1.22.3_1 Message-ID: <4D5880EF.4020002@gmx.de> In-Reply-To: <4D5852F7.2010106@uffner.com> References: <4D5852F7.2010106@uffner.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D5880EF.4020002>