reassign 751886 haskell-curl retitle 751866 haskell-curl: segfault when using TLS due to gnutls28 using nettle/GMP thanks
Hi, I'm reassigning this to haskell-curl. After extensive analysis, it turns out that this is most probably a memory corruption issue triggered by gnutls28 using GMP. In short, GHC uses GMP for its Integer and Fractional implementation and the GHC RTS manages the process-wide GMP stack using its garbage collector[1]. libcurl3-gnutls, as used by the Haskell curl bindings, pulls in gnutls28 which relies on nettle and GMP for low-level crypto material manipulation. Since the curl bindings use the Haskell FFI to call libcurl functions, the eventual calls to GMP functions go unnoticed by the Haskell runtime, yet GnuTLS's GMP uses the Haskell-managed heap (because that's a process-wide GMP setting). Eventually, the GHC garbage collector runs and corrupts the TLS keying material used by curl, giving either a segfault, or a corrupted cryptographic signature (TLS "Decrypt error" alert). Indeed, building ganeti with -debug and -rtsopts, there is a clear correlation between increasing the allocation area size (+RTS -Ax) and reducing the possiblity of a crash. Since a) gnutls26 (which was not using nettle/GMP) is bound to go away and gnutls28 depends strictly on nettle/GMP; b) building GHC without gmp (using integer-simple) incurs a performance hit; c) the GMP calls happen significantly below the curl bindings and cannot be managed at the curl binding level; the most feasible solution seems to be rebuilding the curl bindings against the OpenSSL or NSS variants of libcurl3, at the cost of possible licensing issues. Regards, Apollon [1] https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes/TheCurrentGMPImplementation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org