CVE-2007-0002: Various problems were fixed in the Wordperfect converter library libwpd in OpenOffice_org which could be used by remote attackers to potentially execute code or crash OpenOffice_org. CVE-2007-0238: A stack overflow in the StarCalc parser could be used by remote attackers to potentially execute code by supplying a crafted document. CVE-2007-0239: A shell quoting problem when opening URLs was fixed which could be used by remote attackers to execute code by supplying a crafted document and making the user click on an embedded link.
Ccing herd
Very non-helpful description from Novell. Tough to figure out, when or where this is fixed. As Novell is using ooo-build, I guess the latest unstable release of OOo should be fine (tough we might have to revision bump it, as the fix might have come in one of the silent patchset-updates we did). About 2.0.4: No clue. openoffice-bin is even more up in the air... Anyway, to much guessing here, so will try to catch someone from Novell about that.
I think the fixes should be in the upcoming 2.2 scheduled for release late this month.
(In reply to comment #3) > I think the fixes should be in the upcoming 2.2 scheduled for release late this > month. > Ok, so what I've found out now: The report was more or less issued by accident, this should have waited until 2.2. openoffice-bin-2.2-rcs should be fine 2.1 is NOT. Unfortunately for binary patches or the new stable release we have to wait for upstream. openoffice-2.1.0 currently in portage is also NOT fixed (with the exception of the libwpd-fix) That's as bad as we stand now.
Updating whiteboard.
I have the necessary patches for openoffice-2.1.0 now, am building right now. Will be doing a revision bump with this patches afterwards, I guess we should mark this stable asap. (OOo 2.1.0 is ready for going stable anyway) For openoffice-bin I'm afraid we have to wait for the 2.2-release.
openoffice-2.1.0-r1 (including the security patches) built fine, so the question now is: How do we handle this? Should I put it into portage (and if yes mention this bug?) or wait until we have a fixed binary version, too? Never had such a situation, so waiting for advice.
Yes it is kind of akward. Our normal procedure is to put it into Portage and only mention this bug. Did any other vendors put out fixes and sources?
(In reply to comment #8) > Yes it is kind of akward. Our normal procedure is to put it into Portage and > only mention this bug. Did any other vendors put out fixes and sources? > Not that I know of, but I guess you are better in checking this than me...
CVE-2007-0002 is definately public. It appears that the other issues are public here: https://www.redhat.com/archives/fedora-cvs-commits/2007-February/msg01237.html If that is the case just go ahead and commit.
2.1.0-r1 is in portage now, so I guess the work to mark it stable can start.
I've also commited the most current RC of openoffice-bin-2.2, which should have those fixes too. Though as it being a RC I've hard-masked it. I guess we should wait for the final with this (which is scheduled for next Thursday atm)
Thx Suka. Arch Security Liaisons please test and mark stable: openoffice-2.1.0-r1.ebuild:KEYWORDS="~amd64 ppc sparc x86" openoffice-bin-2.2.0_rc3.ebuild:KEYWORDS="amd64 x86" Looks like sparc will be a problem and could need a mask.
(In reply to comment #13) > Thx Suka. > > Arch Security Liaisons please test and mark stable: > > openoffice-2.1.0-r1.ebuild:KEYWORDS="~amd64 ppc sparc x86" > openoffice-bin-2.2.0_rc3.ebuild:KEYWORDS="amd64 x86" > > Looks like sparc will be a problem and could need a mask. > Just to re-emphasize this: Do we really want to mark a release candidate stable? Shouldn't we wait for the final?
Ok, valid point. To rephrase: Arch Security Liaisons please test and mark stable: openoffice-2.1.0-r1.ebuild:KEYWORDS="~amd64 ppc sparc x86" And at your option mark the release candidate stable, otherwise we'll wait for the final which should hopefully arrive before the end of the month. openoffice-bin-2.2.0_rc3.ebuild:KEYWORDS="amd64 x86" Looks like sparc will be a problem and could need a mask.
The sparc aspect of things is somewhat complex: openoffice-2.0.* only works with the current stable toolchain (gcc-3.4.x) >=openoffice-2.1 only works with the new toolchain (gcc-4.1.x, shipping for 2007.0) - but we just got it to build, not work correctly yet. gcc4 is required because of STLport-5.1.0. I'm working with suka on getting 2.1+ into some working form, though it's currently not high-priority in my list.
Arch security liaisons, any news on this one?
(In reply to comment #17) > Arch security liaisons, any news on this one? Compiles fine on ppc (tested several combinations of use-flags), what about =sys-libs/db-4.3.29-r2 which also needs to be marked stable? Someone already talked to caleb/paul about that?
Pulling in paul and caleb to advise on any possible problems related to the =sys-libs/db-4.3.29-r2 dep.
The db version can certainly be stabilized, it hasn't changed interestingly for over half a year. I don't think strict requirements are wise though. It is also not needed as this version is the only 4.3 version around.
Hmmm, maybe I just don't get it, but what =sys-libs/db-4.3.29-r2 dep are you talking about?
@suka: sys-libs/db-4.3.29-r2 is pulled in by the >=sys-libs/db-4.3 dep and latest stable on any arch it appears is sys-libs/db-4.2.52_p4-r2.
(In reply to comment #22) > @suka: sys-libs/db-4.3.29-r2 is pulled in by the >=sys-libs/db-4.3 dep and > latest stable on any arch it appears is sys-libs/db-4.2.52_p4-r2. > Yeah, I know, I just wanted to point out that there is no strict dependency on that one version like Paul seems to have thought.
openoffice-bin-2.2.0 is in the tree now, so please look at it and mark stable (and don't forget about openoffice...) maybe we should make this bug public again?
I can't connect to the CVS server so no target keywords. Archs if you are in doubt just post on this bug. Opening bug since this is public now.
ppc stable
openoffice-bin-2.2.0 stable on x86. Sorry, I do not have time to compile OOo from source - laptop has to go with me to work tomorrow, where it will be tortured by booting Windows on it.
2.1.0-r1 stable on x86
agreed with paul - there should be no issues marking db 4.3 stable
maybe someone should check if bug 172860 is x86 specific before stabling continues . according to bug 172860 comment #3 this is quite possible, but who knows...
openoffice-bin-2.2.0 emerges fine and works on amd64, as it's -bin it's not affected by bug 172860 openoffice-2.1.0-r1 emerges fine and works for me too, but that's never marked stable on amd64 :> Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.20-beyond2 x86_64) ================================================================= System uname: 2.6.20-beyond2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 02 Apr 2007 10:50:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -msse3 -w" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe -msse3 -w" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet" FEATURES="buildsyspkg ccache collision-protect distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ " LANG="en_US.ISO8859-15" LC_ALL="en_US.ISO8859-15" MAKEOPTS="-j3 -l3 -s --no-print-directory" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/overlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acpi alsa amd64 amr audiofile berkdb bitmap-fonts bzip2 cairo cdinstall cdr cli cracklib crypt cups dbus dri dts dvd dvdr dvdread emboss encode fam firefox fortran gdbm gif gpm gstreamer gtk gtk2 hal iconv jpeg libg++ logrotate mad midi mikmod mp3 mpeg ncurses nptl nptlonly offensive ogg opengl pam pcre php png ppds pppd quicktime readline reflection sdl session smp spl ssl svg symlink tcpd test tiff truetype truetype-fonts type1-fonts unicode v4l vim vorbis x264 xinerama xorg xv xvid zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="inputlirc" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
We really should get this done soonish. So what's still missing from my perspective: AMD64 marking openoffice-bin-2.2.0 stable sparc deciding on what to do now, as no version of openoffice seems to build atm. Could we please have feedback on both?
Just p.mask it/remove keywords for us. I'll look into getting the new one working when i've got time which i kind of lack for at least this week.
(In reply to comment #33) > Just p.mask it/remove keywords for us. > I'll look into getting the new one working when i've got time which i kind of > lack for at least this week. > Ok, I'll just remove 2.0.4 from the tree then, so this is "sorted out" more or less automatically.
*** Bug 173338 has been marked as a duplicate of this bug. ***
openoffice-bin-2.2.0 is now stable on amd64, openoffice-2.1.0-r1 is already ~amd64.
This time i remembered to remove amd64@... sorry 'bout teh bugspam.
I've removed openoffice-bin-2.1.0 from the tree now. As far as I can see, everything is set for the GLSA.
200704-12, thanks everybody! sorry for the delay
