Problems with plugin for pidgin

[ttlmax]

First of all, great project and thanks for providing this.

Unfortunately I have problems running the plugin in pidgin 2.13.0. A connection is established (the connection with openMittsu is interrupted as soon as pidgin connects) but I encounter the following issues:

• Adding a user is not possible, since the account is not shown in the drop down list for selection the threema account (on Debian 10 with Gnome)
• Adding a user crashes pidgin (on Ubunut 18.04 LTS with Gnome) but the account is available in the drop down list
• Sending an message to a new user (user name = threema id?) opens a chat window but any message sent just disappears without being echoed in the chat window
• Receiving a message does not open a chat window but gives the error message: "Unsupported TLS library used by CURL"

Maybe it is just some sort of mis-configuration, is there any kind of readme or documentation?

Best, Torsten

[hbruintjes]

The last three issues may all be related: If the right TLS library is not compiled in, this may lead to any of the displayed behavior (which aside from the last are all bugs). Not sure about the first, once threepl is loaded it should be possible to add a user. Does anything of interest pop-up when running pidgin with debug output? (i.e. start in terminal with command option -d).

Re. CURL issue: Both Ubuntu and Debian by default use OpenSSL AFAIK, so standard configuration should work. Can you verify that is the case on your platform? Otherwise, the CMake options USE_OPENSSL, USE_MBEDTLS or USE_WOLFSSL may have to be changed.

[ttlmax]

Thanks for the prompt reply.

The debugging option does not reveal anything more useful than
threepl: ERROR - Unsupported TLS library used by CURL

My system is using OpenSSL (version 1.1.0g). The relevant entries in CMakeCache.txt are:

CMakeCache.txt:OPENSSL_CRYPTO_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libcrypto.so
CMakeCache.txt:OPENSSL_INCLUDE_DIR:PATH=/usr/include
CMakeCache.txt:OPENSSL_SSL_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libssl.so
CMakeCache.txt://Add mbedTLS/PolarSSL support
CMakeCache.txt://Add OpenSSL support
CMakeCache.txt:USE_OPENSSL:BOOL=ON
CMakeCache.txt://Add wolfSSL/cyaSSL support
CMakeCache.txt:USE_WOLFSSL:BOOL=OFF
CMakeCache.txt:ceema_LIB_DEPENDS:STATIC=general;/usr/lib/x86_64-linux-gnu/libcurl.so;general;OpenSSL::SSL;general;OpenSSL::Crypto;general;/usr/lib/x86_64-linux-gnu/libsodium.so;

Should the plugin be listed in the plugin menu? Actually it is not, but probing threepl.so seems to be successful since there are no related complains in the debug output except for a missing icon:

plugins: probing /home/user/.purple/plugins/libthreepl.so
gtkutils: gdk_pixbuf_new_from_file() returned nothing for file /usr/share/pixmaps/pidgin/protocols/16/threema.png: Failed to open file '/usr/share/pixmaps/pidgin/protocols/16/threema.png': No such file or directory

[hbruintjes]

No menu item is expected, until you add an account. Then the account menu should list some Threema-specific options. The missing pixmap message however is a good sign, since the plugin is then being loaded. It could be a few things have changed in the purple APIs in the meanwhile, causing things to stop working. I'll have to look into it.

[ttlmax]

I have found the issue: On my system, curl uses the gnutls backend. After having compiled curl with the mbedtls backend and a fix in HttpClientmbedTLS.cpp (the size for parsing the certificate has to be increased by one) the plugin is working now.

[myxor]

@ttlmax do your changes maybe help for solving #1 ?
Did you manage or could you try to remove the OpenSSL dependencies?

[ttlmax]

I can't remember exactly and will look into this the next days.

[ttlmax]

In my main CMakeLists.txt I have selected mbedTLS and a self compiled CURL lib:

# Find any of OpenSSL, mbedTLS or CyaSSL, as these are currently supported for
# CURL certificate callbacks
option(USE_OPENSSL "Add OpenSSL support" OFF)
option(USE_MBEDTLS "Add mbedTLS/PolarSSL support" ON)
option(USE_WOLFSSL "Add wolfSSL/cyaSSL support" OFF)

if (NOT USE_OPENSSL AND NOT USE_MBEDTLS AND NOT USE_WOLFSSL)
    message(SEND_ERROR "At least one SSL library is required")
endif ()

# Give the user the possibility to provide the path to a possibly self compiled
# CURL lib. Some linux distros have CURL with GnuTLS backend which does not
# provide the required CURL certificate callback. Thus CURL has to be manually
# compiled with another backend, like, e.g., mbedTLS
option(USE_OWN_CURL_LIB "Use manually compiled CURL lib" ON)

The CURL lib is self-compiled with mbedTLS, i.e.

./configure --without-ssl --with-mbedtls --prefix $HOME/Software/threema/threepl-ttl/3rdparty/curl --exec-prefix=$HOME/Software/threema/threepl-ttl/3rdparty/curl

Thus, I think that there are no dependencies on openssl (or am I missing something?). Running ldd on linthreema.so and libcrul.so does not show any refs to openssl.

Best
Torsten

[myxor]

@ttlmax i know this topic is a little bit old but i am trying to get this working with self compiled CURL.
I compiled CURL with mbedTLS but i am a little stuck on how to link my CURL into this.

[ttlmax]

myxor, sorry, I missed your port. I have used the following at the beginning fo the file src/CMakeLists.txt:

# A self compiled CURL lib has to be installed in /3rdparty/curl, which
# is contained in .gitignore and is not trakced by git
if (USE_OWN_CURL_LIB)
    set (CURL_INCLUDE_DIRS  "${CMAKE_SOURCE_DIR}/3rdparty/curl/include")
    set (CURL_LIBRARIES     "${CMAKE_SOURCE_DIR}/3rdparty/curl/lib/libcurl.so")
endif ()

Hope this helps.