Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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