Hi genone, you've just stabilized 2.0 but there is a little security issue in this branch. Well, i can't really confirm if 2.0 is affected since there is little information on this issue. But if the phishing URI checker doesn't exist in 2.0, that is another security issue. In both case, please upgrade to 2.2.2 . -------------------------------------------------- Software: Sylpheed-Claws 2.x Description: A security issue has been reported in Sylpheed-Claws, which potentially can be exploited by malicious people to bypass certain security restrictions. The security issue is caused due to an error within /src/common/utils.c when handling an URI that starts with a space character. This can potentially be exploited to bypass the phishing URI checker due to the failure to identify certain fake or phishing URIs that began with a space. The security issue has been reported in versions prior to 2.2.2. Solution: Update to version 2.2.2. http://sourceforge.net/project/showfiles.php?group_id=25528 Provided and/or discovered by: Reported by the vendor. Original Advisory: http://sourceforge.net/project/s...ase_id=422662&group_id=25528
This hardly seems like a security issue to me.
Upstream confirms that this issue also affects 2.0.x. 2.2.2 should not be used, since it contained a rather nasty bug, which was promptly fixed in 2.2.3.
genone or net-mail, do you think this is a security issue which merits to be fixed in the stable tree ? (in such case please provide a 2.2.3 ebuild if possible)
genome/net-mail, your opinion on this ?
2.2.3 and 2.3.0 in the tree. As for if this is a sec issue or not: I honestly don't have a clue how that check works/what it does, so can't comment on that.
Fixing component. I don't really think this is a serious security issue. Arches please test and mark stable.
sylpheed-claws-2.2.3 stable on ppc64
testing x86...
Seems to work here. Now pinging about open bugs #116083 and #126848
Bug #126848 closed, one to go...
I was born on a Sunday, by Tuesday I was SPARCin' me an ebuild.
x86 stable
ppc stable
Freezes on amd64. When I start the program it prints "/home/tcort/.sylpheed-claws/sylpheedrc: fopen: No such file or directory" to the console and then gives me the usual wizard for entering a new account. Just clicking Forward a bunch of times and then clicking save causes it to lock up. I don't know if it makes a difference or not, but I have sylpheed installed on the system too. mail-client/sylpheed-claws-2.3.0 USE="crypt gnome ipv6 kde spell ssl -clamav -dillo -doc -imap -ldap -pda -spamassassin -startup-notification -xface" Portage 2.1 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r7 x86_64) ================================================================= System uname: 2.6.15-gentoo-r7 x86_64 AMD Turion(tm) 64 Mobile Technology ML-32 Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 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-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/"CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig cvs distlocks metadata-transfer multilib-strict sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org/" MAKEOPTS="-j2" 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/tcort /usr/portage/local/layman/tcort /usr/portage/local/layman/sunrise" SYNC="rsync://134.68.220.73/gentoo-portage" USE="amd64 X aac acpi aim alsa arts audacious audiofile avi berkdb bitmap-fonts browserplugin bzip2 cli crypt cups dbus dlloader dri eds emboss encode flac foomaticdb gif glut gnome gphoto2 gpm gstreamer gtk gtk2 hal icq imlib ipv6 isdnlog jabber java jpeg kde lua lzw lzw-tiff mad mikmod mono moznocompose moznoirc moznomail mp3 mpeg msn ncurses nls nocd nptl nptlonly nsplugin offensive ogg oggvorbis openal opengl oscar pam pcre pdflib perl png pppd python qt qt3 qt4 quicktime readline reflection sdl session shorten sndfile spell spl ssl symlink tcpd tiff truetype-fonts type1-fonts usb userlocales vorbis wxgtk1 xmms xorg xpm xv xvid yahoo zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Can you please provide output of `sylpheed-claws --debug` when performing described action? Thanks!
(In reply to comment #15) > Can you please provide output of `sylpheed-claws --debug` when performing > described action? Thanks! I ran it with "--debug", and got a bunch of "folder.c:1778:Remembered message X for fetching" and "msgcache.c:118:Cache size: X messages, X bytes" messages. So, it wasn't actually frozen; it was just importing my messages from sylpheed without telling me or providing any sort of output or progress bar. Since I have >15,000 messages, it took a little while and I assumed it was frozen. Once the import was done, it worked well. amd64 stable.
All sec supported arches stable -> closing with NO GLSA. Thx everyone.
(In reply to comment #16) > I ran it with "--debug", and got a bunch of "folder.c:1778:Remembered message X > for fetching" and "msgcache.c:118:Cache size: X messages, X bytes" messages. > So, it wasn't actually frozen; it was just importing my messages from sylpheed > without telling me or providing any sort of output or progress bar. Since I > have >15,000 messages, it took a little while and I assumed it was frozen. Once > the import was done, it worked well. > > amd64 stable. > Just FYI: Incidentally, this has been fixed in CVS just yesterday - there is feedback in main window statusbar. :) Also, should this bug be closed already? There is still hppa...
Reoping bug for hppa to mark stable. /me bangs head against the wall.
(In reply to comment #19) > Reoping bug for hppa to mark stable. > > /me bangs head against the wall. Thanks! We're having some difficulty with 2.3.0 and 2.3.1 generating a message cache. IMAP access works fine, but then it simply freezes and does a lot of pointless scheduling. This might be a signedness/endianness bug in <src/msgcache.[ch]>. Unclear is whether this is a gtk+/glib or a sylpheed-claws bug. A simple update to latest unstable gtk+/glib and a remerge didn't fix it. Haven't had time to really dig into this, sadly. [1] looked kind of suspect at first glance. [1] http://cvs.sunsite.dk/viewcvs.cgi/sylpheedclaws/sylpheed-claws/src/msgcache.c.diff?r1=1.16.2.31&r2=1.16.2.32&only_with_tag=gtk2
Again, please provide output of `sylpheed-claws --debug`, I have notified upstream about this bug. Thanks!
(In reply to comment #20) > Thanks! We're having some difficulty with 2.3.0 and 2.3.1 generating a message > cache. IMAP access works fine, but then it simply freezes and does a lot of > pointless scheduling. This might be a signedness/endianness bug in > <src/msgcache.[ch]>. Unclear is whether this is a gtk+/glib or a sylpheed-claws > bug. A simple update to latest unstable gtk+/glib and a remerge didn't fix it. > Haven't had time to really dig into this, sadly. [1] looked kind of suspect at > first glance. Can you provide a --debug log ? the patch you point to should fix things in fact :)
Created attachment 90938 [details] Output from `strace -f sylpheed-claws'
Created attachment 90940 [details] Output from `sylpheed-claws --debug' All the GUI action that took place on this run is me clicking on a folder with just a few messages in it, after which SC downloaded the headers for those messages and then froze.
(In reply to comment #24) > Created an attachment (id=90940) [edit] > Output from `sylpheed-claws --debug' > > All the GUI action that took place on this run is me clicking on a folder with > just a few messages in it, after which SC downloaded the headers for those > messages and then froze. This looks strange. Can you run via gdb, and when reaching the freeze, hit Ctrl-C and do "backtrace full"? Thanks
> This looks strange. Can you run via gdb, and when reaching the freeze, hit > Ctrl-C and do "backtrace full"? Here you go: jeroen@elmer ~ $ gdb /usr/bin/sylpheed-claws GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa2.0-unknown-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/sylpheed-claws [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 20705)] [New Thread 32769 (LWP 20708)] [New Thread 16386 (LWP 20709)] (sylpheed-claws:20705): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed (sylpheed-claws:20705): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed Program received signal SIGINT, Interrupt. [Switching to Thread 16386 (LWP 20709)] 0x40623030 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) backtrace full #0 0x40623030 in __pthread_sigsuspend () from /lib/libpthread.so.0 No symbol table info available. #1 0x40621e90 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 No symbol table info available. #2 0x40621e90 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 No symbol table info available. Previous frame identical to this frame (corrupt stack?) (gdb) kill Kill the program being debugged? (y or n) y
Ahh, sorry, this info isn't enough. I'd need the result of "thread apply all bt full" instead :)
(In reply to comment #27) > Ahh, sorry, this info isn't enough. I'd need the result of "thread apply all bt > full" instead :) jeroen@elmer ~ $ gdb `which sylpheed-claws` GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa2.0-unknown-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/sylpheed-claws [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 25285)] [New Thread 32769 (LWP 25293)] [New Thread 16386 (LWP 25294)] Program received signal SIGTSTP, Stopped (user). [Switching to Thread 16386 (LWP 25294)] 0x40623030 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) thread apply all bt full Thread 3 (Thread 16386 (LWP 25294)): #0 0x40623030 in __pthread_sigsuspend () from /lib/libpthread.so.0 No symbol table info available. #1 0x40621e90 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 No symbol table info available. #2 0x40621e90 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 No symbol table info available. Previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 32769 (LWP 25293)): #0 0x426761c4 in poll () from /lib/libc.so.6 No symbol table info available. #1 0x42676198 in poll () from /lib/libc.so.6 No symbol table info available. Previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 16384 (LWP 25285)): #0 0x42668214 in sched_yield () from /lib/libc.so.6 No symbol table info available. #1 0x406247b8 in __pthread_acquire () from /lib/libpthread.so.0 No symbol table info available. #2 0x406247b8 in __pthread_acquire () from /lib/libpthread.so.0 No symbol table info available. Previous frame identical to this frame (corrupt stack?) #0 0x40623030 in __pthread_sigsuspend () from /lib/libpthread.so.0
mmh. No idea what the problem is...
(In reply to comment #29) > mmh. No idea what the problem is... > It's probably hppa specific. The very same problem also occurs when running mail-client/evolution, but it happens with media-gfx/gimp too, and is probably caused by some erroneous threading function in glib or gtk+. The bug is very likely not in sylpheed-claws.
@jeroen do we have another bug for the issue?
(In reply to comment #31) > @jeroen do we have another bug for the issue? We do now: bug #141674.
i just change the whiteboard as a reminder and to make things cleaner.
HPPA done. SC-2.4.0 does not work with hppa's current glibc (see bug #141674 for details).
Thanks hppa, i'm a little lost with all that stuff.. re-closing with noglsa. Feel free to reopen if i'm wrong
