Summary: | dev-util/cscope Multiple Vulnerabilities (CVE-2006-4262) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | agriffis, ed, emacs, mkennedy, tcort, vim |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203645 | ||
Whiteboard: | B2 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Sune Kloppenborg Jeppesen (RETIRED)
2006-08-23 09:25:42 UTC
Upstream patches @ http://sourceforge.net/mailarchive/forum.php?thread_id=30266760&forum_id=33500 http://sourceforge.net/mailarchive/forum.php?thread_id=30266761&forum_id=33500 Matthew, would you be so kind so as to bump our cscope with these ? mkennedy any news on this one? I don't have a machine to use for the week. -dev mailed. No answer. Security I suggest a mask, comments? I would mask it, after all -dev was warned about it I just added a snapshot from CVS which will include the fix to this. this was _really_ close to being masked arches pls test and mark stable if possible target KEYWORDS="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc x86 ~x86-fbsd" this time even adding arches to CC ;-) In x86: Compiles and works nice. Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.12.5 Last Sync: Mon, 02 Oct 2006 19:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -mtune=athlon-tbird -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-tbird -mtune=athlon-tbird -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ " LINGUAS="" PKGDIR="/usr/portage/packages" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise" SYNC="rsync://rsync.belnet.be/packages/gentoo-portage" USE="x86 X bitmap-fonts bzip2 cairo cdr cli crypt dbus dlloader dri dvd dvdr eds elibc_glibc emboss encode fam firefox fortran gif gpm gstreamer gtk hal input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kernel_linux ldap libg++ mad mikmod mp3 mpeg ncurses nptl nptlonly ogg opengl pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_vesa vorbis win32codecs xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS So are we talking about marking cscope-15.5.20060927 stable? If so, how do people feel about marking a cvs snapshot stable for their arches? Brent raises a good question here. I guess we should suspend stable marking until we have a comment from mkennedy or vim/emacs. What about an ebuild which just adds the needed patches? We would be running into patch conflicts continuting on from -r6. This means recomputing the patches, and given that cscope was almost removed from the tree due to lack of interest in this security bug, we definitely don't want to make it harder to maintain. CVS is not a fast moving target for cscope. Most development in there seems to be related to security vulnerabilities. We can either make this CVS snapshot stable, or we can remove -r6 from portage, leaving stable without a cscope until this CVS snapshot has had adequate testing. If you want to go with the former, you'll need to check for regressions -- go through the ebuild ChangeLog and make sure the bugs solved there are not reintroduced in the CVS snapshot. (In reply to comment #13) > or we can remove -r6 from portage This would imply masking kscope and changing the vim ebuild accordingly. Even Debian chose to package a snapshot (In reply to comment #13) > or we can remove -r6 from portage This would imply masking kscope and changing the vim ebuild accordingly. Even Debian chose to package a snapshot¹, btw.. [1] http://ftp.debian.org/debian/pool/main/c/cscope/cscope_15.5+cvs20060902-2.diff.gz Any progress here? x86 done. Thanks for reminding. sparc stable. (In reply to comment #16) > x86 done. Thanks for reminding. > Mh, that was more intended to be something like "did someone decide, if we want to stable a snapshot or not?" ... so ... we want to stable a snapshot? mkennedy? i just gave a couple of suggestions, but it looks like it's being decided per arch stable on alpha and amd64. ppc64 stable Stable on ppc. On amd64 and ia64 (at least), "make cscope" in a kernel source tree segfaults with (now stable) cscope-15.5.20060927. It works fine with cscope-1.15-r6. Clearly this isn't ready for release. You might want to file a bug then. emerge --info, a back trace etc. Stable on hppa. (In reply to comment #24) > You might want to file a bug then. emerge --info, a back trace etc. /me looks sheepish Filed as bug 151503 Let's go for a GLSA. bug 151503 seems not very common. GLSA 200610-08 |