Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 440898 - mail-client/claws-mail--3.8.1-r2 with net-libs/gnutls-3.1.3 - crashes on mail check
Summary: mail-client/claws-mail--3.8.1-r2 with net-libs/gnutls-3.1.3 - crashes on mail...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Christian Faulhammer (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: gnutls-3
  Show dependency tree
 
Reported: 2012-11-02 04:00 UTC by Boney McCracker
Modified: 2012-11-04 16:42 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Boney McCracker 2012-11-02 04:00:10 UTC
After upgrading gnutls-2.12.20 to gnutls-3.1.3 and performing emerge --depclean and revdep-rebuild (which rebuilt, among other things, claws-mail), the claws-mail application crashes when trying to retrieve POP3 mail.

Reproducible: Always

Actual Results:  

Starting it from the command line produces the following error messages.
-------------------------------------------------------------------------------

~ $ claws-mail

** (claws-mail:21103): WARNING **: couldn't gnutls_x509_crt_export to get size


** (claws-mail:21103): WARNING **: couldn't gnutls_x509_crt_export to get size b The request is invalid.

Segmentation fault
-------------------------------------------------------------------------------



~ # emerge --info
Portage 2.1.11.31 (default/linux/x86/10.0, gcc-4.6.3, glibc-2.16.0, 3.6.4-gentoo i686)
=================================================================
System uname: Linux-3.6.4-gentoo-i686-Intel-R-_Pentium-R-_4_CPU_1300MHz-with-gentoo-2.2
Timestamp of tree: Thu, 01 Nov 2012 08:45:01 +0000
ld GNU ld (GNU Binutils) 2.23
ccache version 3.1.8 [enabled]
app-shells/bash:          4.2_p37
dev-java/java-config:     2.1.12
dev-lang/python:          2.7.3-r2, 3.2.3-r1
dev-util/ccache:          3.1.8
dev-util/cmake:           2.8.9-r1
dev-util/pkgconfig:       0.27.1
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.2
sys-apps/sandbox:         2.6
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.12.4
sys-devel/binutils:       2.23
sys-devel/gcc:            4.6.3
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.6 (virtual/os-headers)
sys-libs/glibc:           2.16.0
Repositories: gentoo local-portage
ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="*"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="ftp://ftp.gtlib.gatech.edu/pub/gentoo http://gentoo.osuosl.org/ http://open-systems.ufl.edu/mirrors/gentoo "
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,--hash-style=gnu,-O1 -Wl,--as-needed"
LINGUAS="en_US en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="X alsa berkdb bzip2 cairo caps cli cracklib crypt cups cxx dri exif ffmpeg gdbm gif gpm gtk iconv java jpeg lcms mmx modules mp3 mudflap ncurses nls nptl nsplugin ogg opengl openmp pam pcre png readline session sse sse2 ssl svg theora threads tiff truetype unicode vorbis win32codecs x86 xcb zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_US en" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 Duncan 2012-11-02 09:04:42 UTC
I'm seeing this too.  Rebuilding claws-mail doesn't help.

But probably unlike most, I've had > gnutls-3 unmasked locally for quite some time, and it was working just fine with gnutls-3.1.2, which I was running before the upgrade.

So it's definitely either a gnutls-3.1.3 specific issue, or there's another factor involved (maybe something else needs rebuilt too?  revdep-rebuild doesn't spot anything) as well.

(Note to the OP and to others who may have the problem and may want to try gnutls-3.1.2.  gnutls-3.1.2 was removed from the tree when 3.1.3 was added but it should still be available from gentoo's cvsweb repo access, if you want to grab it from there.  I still have a 3.1.2 ebuild copy in my overlay from the earlier 3.1.3 pre-unmasking parallel make bug, so I won't have to resort to digging it out of cvsweb, here.  There's a couple of changes between the 3.1.2 and 3.1.3 ebuilds so you can't simply copy the 3.1.3 ebuild to 3.1.2 and ebuild manifest; get the 3.1.2 ebuild from cvsweb.)

Next question:  What were the changes between 3.1.2 and 3.1.3 that may trigger this error and segfault?

Duncan
Comment 2 avx 2012-11-02 09:55:33 UTC
Same problem on AMD64, currently running `emerge -e claws-mail`, though I doubt it'll help.
Comment 3 Duncan 2012-11-02 10:06:45 UTC
Some quick notes:

1) $ readelf -s /usr/lib/libgnutls.so.28 | grep x509_crt_export
000000300a28  030f00000007 R_X86_64_JUMP_SLO 0000000000088900 gnutls_x509_crt_export + 0
   783: 0000000000088900    99 FUNC    GLOBAL DEFAULT   11 gnutls_x509_crt_export@@GNUTLS_1_4
   789: 0000000000088b20    91 FUNC    GLOBAL DEFAULT   11 gnutls_x509_crt_export2@@GNUTLS_3_1_0

The symbol's there.


2) Based on earlier claws-mail gnutls related bugs, I tried remerging libgcrypt and libtasn1, no effect.


3) /usr/share/doc/gnutls*/NEWS.* says in the api/abi changes section that x509_crt_export2 was added.  Nothing about removing/changing the original *_export however.


4) Grepping the claws-mail-3.8.1 sources, there are three instances of "to get size", as seen in the warnings.  All three are in ssl_certificate.c, lines 103, 424, 430.  Line 103 is the plain "size" variant, occurring in gnutls_x509_crt x509_crt_copy.  Line 424 is a "size a" variant that we don't get.  Line 430 is the "size b" variant, occurring in ssl_certificate_compare.
Comment 4 Maxim Britov 2012-11-02 11:26:01 UTC
2012-10-13 [paul]	3.8.1cvs99	* src/common/ssl_certificate.c
    fix build with gnutls 3.1.3
    Patch by Sean Buckheister.

http://www.claws-mail.org/tracker/getpatchset.php?ver=3.8.1cvs99
Comment 5 Duncan 2012-11-02 11:54:24 UTC
Here's the gdb bt, from initialization of the ssl socket (ssl_init_socket_with_method).  claws-mail built normally, gnutls built with -ggdb in CFLAGS and FEATURES=nostrip.

Program received signal SIGSEGV, Segmentation fault.
check_if_same_cert (cert1=0x0, cert2=0x10869d0) at verify.c:81
81      verify.c: No such file or directory.
(gdb) bt
#0  check_if_same_cert (cert1=0x0, cert2=0x10869d0) at verify.c:81
#1  0x00007ffff4cf6144 in _gnutls_x509_verify_certificate (
    certificate_list=certificate_list@entry=0x7fffffffb0f8, clist_size=clist_size@entry=1, 
    trusted_cas=0xdcbbc0, tcas_size=152, flags=0, func=func@entry=0x0) at verify.c:627
#2  0x00007ffff4cf63c7 in gnutls_x509_crt_verify (cert=0x0, CA_list=<optimized out>, 
    CA_list_length=<optimized out>, flags=<optimized out>, verify=0x7fffffffb120)
    at verify.c:848
#3  0x00000000005c495e in ssl_certificate_check_signer ()
#4  0x0000000000622fd5 in ?? ()
#5  0x0000000000623ecd in ?? ()
#6  0x00000000005b82b7 in ?? ()
#7  0x00007ffff5565494 in g_hook_list_marshal () from /usr/lib64/libglib-2.0.so.0
#8  0x00000000005b8944 in hooks_invoke ()
#9  0x00000000005c4b1d in ssl_certificate_check ()
#10 0x00000000005c3a55 in ssl_init_socket_with_method ()


Line 80 and 81 of gnutls-3.1.3/lib/x509/verify.c:

cmp:
  result = _gnutls_x509_der_encode (cert1->cert, "", &cert1bin, 0);

(I'll try the patch linked in comment #4 next, but had this ready to go when I refreshed and saw it.)
Comment 6 Duncan 2012-11-02 12:26:59 UTC
The patch linked in comment #4 works.

Here, all I had to do was drop it as gnutls313.patch in /etc/portage/patches/mail-client/claws-mail/, but I didn't check whether the ebuild would normally apply user_patches or if my hack to get it to always apply them was triggered.
Comment 7 Derk W te Bokkel 2012-11-02 15:50:04 UTC
yes patch works as per comment 6
Comment 8 avx 2012-11-03 04:07:44 UTC
Is epatch_user globally activated now? Also just put the patch in /etc/... and it worked for me.
Comment 9 Duncan 2012-11-03 06:13:18 UTC
(In reply to comment #8)
> Is epatch_user globally activated now?

No, it's not.  That's why I said I had a hack...

epatch_user is called by base_src_prepare in base.eclass, however (base in turn inherits it from eutils), which a lot of ebuilds inherit, so if that default src_prepare is used, it's automatically activated.  A number of other eclasses handle it the same way.

But, not only is it not always called, some ebuilds (I believe from early EAPIs, which must do so specifically) don't inherit the appropriate eclasses and thus don't even make the function available, let alone actually call it.

But I've hacked around that here using /etc/portage/bashrc.  Warning, the below is definitely a hack.  As such it could stop working  (jed are my initials, I needed a name that wasn't likely to be used by anything in-tree, and post_src_prepare is a hook function exposed by portage for exactly this sort of thing)...

In /etc/portage/bashrc:

post_src_prepare () {
        . epatch_jed
}

In /usr/local/sbin/epatch_jed:

# user-patch helper, in case base.eclass isn't inherited
type epatch_user >/dev/null 2>&1 && epatch_user || {
        bash -c " . $PORTDIR/eclass/eutils.eclass 2>&- ; epatch_user "
}

I used the child-shell invocation there to avoid contaminating the environment portage is directly exposed to, and to close STDERR, since directly sourcing an eclass like that is NOT how they're designed to work.  But it does the job of getting the epatch_user function defined, while keeping it in sync with the eutils.eclass version since it sources it.  Absolutely a horrible hack, but it works... until somebody breaks it since I'm using eutils in a way it was most definitely NOT intended to be used, anyway.  Once it's defined, I can invoke it normally.

Thus I force it to run on ALL ebuilds, regardless of whether the ebuild actually inherits eutils.eclass (directly or indirectly) or not, and regardless of whether it's actually invoked by the ebuild or not.

Meanwhile, invoking epatch_user is defined as mandatory in EAPI-5, which has been approved and should be supported in current versions of all three package managers, but they're waiting a few weeks before actually allowing it in-tree, in ordered to work the bugs out and to give users a chance to upgrade to a PM supporting the new EAPI.  The ebuild author/maintainer still gets to choose where it's invoked, but not invoking it at all while claiming EAPI-5 is invalid, and I believe repoman checks for it.

So the problem will gradually resolve itself as the tree switches to EAPI-5+.

> Also just put the patch in /etc/... and it worked for me.

For me, the frustration was not knowing whether it was going to work or not.  It almost made it not worth the trouble; just copy the ebuild to the overlay and add the patch there, since that's actually reliable.  So I hacked up a solution so it WAS always applied, thus gaining the consistency the default solution lacked.
Comment 10 Piotr Szymaniak 2012-11-04 14:05:28 UTC
Got the same issue, the patch helps.
Comment 11 Christian Faulhammer (RETIRED) gentoo-dev 2012-11-04 16:42:06 UTC
Thanks everybody for the effort and time invested in this issue.  I have bumped 3.8.1-r3 although a new Claws release will be done on 14.11.2012 with this fix included.