Bug 375410 - Can't fetch email from oauth configured GMail account
Summary: Can't fetch email from oauth configured GMail account
Status: RESOLVED DOWNSTREAM
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: GIT (master)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Mollekopf
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-22 15:01 UTC by Alex Fiestas
Modified: 2018-11-06 11:23 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Fiestas 2017-01-22 15:01:03 UTC
After configuring the account via oauth, the resource does not seem to be able to connect.

akonadi output:

Pass a valid window to KWallet::Wallet::openWallet().
org.kde.pim.kimap: sasl_client_start failed with: -4 "SASL(-4): no mechanism available: No worthy mechs found"
org.kde.kgapi.raw: Requesting token refresh:  "client_id=554266.apps.googleusercontent.com&client_secret=mdT1T0gO&refresh_token=1/f1A&grant_type=refresh_token"
org.kde.kgapi: Queued QUrl("https://accounts.google.com/o/oauth2/token")
org.kde.kgapi: KGAPI2::AuthJob(0x236f7d0) Dispatching request to QUrl("https://accounts.google.com/o/oauth2/token")
org.kde.kgapi.raw: "client_id=55404.apps.googleusercontent.com&client_secret=mdT1DjzohxN&refresh_token=1/f1AHBA&grant_type=refresh_token"
org.kde.kgapi: Received reply from QUrl("https://accounts.google.com/o/oauth2/token")
org.kde.kgapi: Status code:  200
org.kde.kgapi.raw: "{\n  \"access_token\" : \"["another deleted token"]",\n  \"expires_in\" : 3600,\n  \"id_token\" : \"["DELETED TOKENHERE"]\",\n  \"token_type\" : \"Bearer\"\n}"
org.kde.kgapi: 
Pass a valid window to KWallet::Wallet::openWallet().
qt.network.ssl: QSslSocket::startClientEncryption: cannot start handshake on non-plain connection
org.kde.pim.akonadicore: "QLocalSocket: Socket operation timed out" "/tmp/akonadi-afiestas.Z3ui6I/akonadiserver-cmd.socket"
org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket: Socket operation timed out"
org.kde.pim.akonadi_indexer_agent: Failed to fetch items:  "Cannot connect to the Akonadi service."
org.kde.pim.akonadi_indexer_agent: Indexing failed:  ""
org.kde.pim.akonadicore: Invalid command, the world is going to end!
QIODevice::read (QLocalSocket): device not open
org.kde.pim.kimap: Connection to server lost  0
org.kde.pim.imapresource: Session login cancelled
org.kde.pim.kimap: Connection to server lost  0
org.kde.pim.imapresource: Session login cancelled
Pass a valid window to KWallet::Wallet::openWallet().
Pass a valid window to KWallet::Wallet::openWallet().
org.kde.pim.kimap: sasl_client_start failed with: -4 "SASL(-4): no mechanism available: No worthy mechs found"
Comment 1 Daniel Vrátil 2017-02-04 16:37:00 UTC
Could you please provide output from the "pluginviwer" utility?

The message from SASL (SASL(-4): no mechanism) indicates that SASL cannot find the XOAUTH plugin. If you have PIM installed in a prefix, you may need to manually copy libkdexoauth.so to /usr/lib64/sasl2/ because SASL loads plugins only from there and ignores LD_LIBRARY_PATH and similar.
Comment 2 Carlos De Maine 2017-02-05 22:19:13 UTC
On kde neon dev edition, kdepim-runtime installs libkdexoauth2.so to:

carlos@carlos-N55SF:/usr/lib/x86_64-linux-gnu/sasl2$ ls
libanonymous.so         libdigestmd5.so.2       libntlm.so         libplain.so.2
libanonymous.so.2       libdigestmd5.so.2.0.25  libntlm.so.2       libplain.so.2.0.25
libanonymous.so.2.0.25  libkdexoauth2.so.3      libntlm.so.2.0.25  libsasldb.so
libcrammd5.so           libkdexoauth2.so.3.0.0  libotp.so          libsasldb.so.2
libcrammd5.so.2         liblogin.so             libotp.so.2        libsasldb.so.2.0.25
libcrammd5.so.2.0.25    liblogin.so.2           libotp.so.2.0.25
libdigestmd5.so         liblogin.so.2.0.25      libplain.so

saslpluginviewer reports:

carlos@carlos-N55SF:/usr/lib/x86_64-linux-gnu/sasl2$ saslpluginviewer 
Installed and properly configured auxprop mechanisms are:
sasldb
List of auxprop plugins follows
Plugin "sasldb" ,       API version: 8
        supports store: yes

Installed and properly configured SASL (server side) mechanisms are:
  DIGEST-MD5 EXTERNAL OTP CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
Available SASL (server side) mechanisms matching your criteria are:
  DIGEST-MD5 OTP CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
List of server plugins follows
Plugin "digestmd5" [loaded],    API version: 4
        SASL mechanism: DIGEST-MD5, best SSF: 128, supports setpass: no
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|MUTUAL_AUTH
        features: PROXY_AUTHENTICATION|SUPPORTS_HTTP
Plugin "otp" [loaded],  API version: 4
        SASL mechanism: OTP, best SSF: 0, supports setpass: yes
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|FORWARD_SECRECY
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION
Plugin "crammd5" [loaded],      API version: 4
        SASL mechanism: CRAM-MD5, best SSF: 0, supports setpass: no
        security flags: NO_ANONYMOUS|NO_PLAINTEXT
        features: SERVER_FIRST
Plugin "ntlm" [loaded],         API version: 4
        SASL mechanism: NTLM, best SSF: 0, supports setpass: no
        security flags: NO_ANONYMOUS|NO_PLAINTEXT
        features: WANT_CLIENT_FIRST|SUPPORTS_HTTP
Plugin "plain" [loaded],        API version: 4
        SASL mechanism: PLAIN, best SSF: 0, supports setpass: no
        security flags: NO_ANONYMOUS|PASS_CREDENTIALS
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION
Plugin "login" [loaded],        API version: 4
        SASL mechanism: LOGIN, best SSF: 0, supports setpass: no
        security flags: NO_ANONYMOUS|PASS_CREDENTIALS
        features:
Plugin "anonymous" [loaded],    API version: 4
        SASL mechanism: ANONYMOUS, best SSF: 0, supports setpass: no
        security flags: NO_PLAINTEXT
        features: WANT_CLIENT_FIRST|DONTUSE_USERPASSWD
Installed and properly configured SASL (client side) mechanisms are:
  DIGEST-MD5 EXTERNAL OTP CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
Available SASL (client side) mechanisms matching your criteria are:
  DIGEST-MD5 EXTERNAL OTP CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
List of client plugins follows
Plugin "digestmd5" [loaded],    API version: 4
        SASL mechanism: DIGEST-MD5, best SSF: 128
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|MUTUAL_AUTH
        features: PROXY_AUTHENTICATION|NEED_SERVER_FQDN|SUPPORTS_HTTP
Plugin "EXTERNAL" [loaded],     API version: 4
        SASL mechanism: EXTERNAL, best SSF: 0
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_DICTIONARY
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION
Plugin "otp" [loaded],  API version: 4
        SASL mechanism: OTP, best SSF: 0
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|FORWARD_SECRECY
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION
Plugin "crammd5" [loaded],      API version: 4
        SASL mechanism: CRAM-MD5, best SSF: 0
        security flags: NO_ANONYMOUS|NO_PLAINTEXT
        features: SERVER_FIRST
Plugin "ntlm" [loaded],         API version: 4
        SASL mechanism: NTLM, best SSF: 0
        security flags: NO_ANONYMOUS|NO_PLAINTEXT
        features: WANT_CLIENT_FIRST|SUPPORTS_HTTP
Plugin "plain" [loaded],        API version: 4
        SASL mechanism: PLAIN, best SSF: 0
        security flags: NO_ANONYMOUS|PASS_CREDENTIALS
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION
Plugin "login" [loaded],        API version: 4
        SASL mechanism: LOGIN, best SSF: 0
        security flags: NO_ANONYMOUS|PASS_CREDENTIALS
        features: SERVER_FIRST
Plugin "anonymous" [loaded],    API version: 4
        SASL mechanism: ANONYMOUS, best SSF: 0
        security flags: NO_PLAINTEXT
        features: WANT_CLIENT_FIRST

so it appears the plugin is built and installed to the correct position but sasl isnt loading it.  Plugin version mismatch??
Comment 3 Carlos De Maine 2017-02-12 03:39:44 UTC
Finally got this working.  There needs to be a symbolic link pointing from libkdexoauth2.so to libkdexoauth2.so.3.  Sasl then finds the plugin and all is peachy!  Is this a cmake problem or a packaging problem?
Comment 4 Daniel Vrátil 2017-03-09 07:03:30 UTC
Looks like a packaging error, distributions tend to include .so symlinks in their -dev sub-packages but in this case, we need to have the .so in the main package, because it's a plugin. Please open a ticket in your distribution's tracker.

(marking as resolved, this is a downstream/packaging issue)
Comment 5 Fabian Vogt 2018-10-04 17:39:12 UTC
(In reply to Daniel Vrátil from comment #4)
> Looks like a packaging error, distributions tend to include .so symlinks in
> their -dev sub-packages but in this case, we need to have the .so in the
> main package, because it's a plugin. Please open a ticket in your
> distribution's tracker.
> 
> (marking as resolved, this is a downstream/packaging issue)

I would say this is partially due to upstream.
Plugins installing a .so with versioning does not make sense and should be avoided.
That's likely how the mistake happened in the first place.

I just tried removing the SOVERSION/VERSION in libkgapi/src/saslplugin and the cyrus-sasl pluginviewer still showed the plugin. I'm not sure why the cyrus-sasl plugins use 3.0.0 though.