In the past I just the Digikam export tool to export photos to Google photos. When I tried to use 5.7.0 access to my account was not possible and the plugin tried to request a new Google token. The token is successfully requested. After copying the token into the plugin window the plugin and Digikam crash. I can reproduce this error with Digikam 5.7.0 and 5.6.0 appimage. My configuration: Ubuntu 17.04 on VirtualBox MySQL Thanks for helping PK
I can not reproduce the crash here. Can you create a GDB backtrace? Maik
No crash from here too, under Mageia Linux 6 and from France. Code is git/master. Gilles Caulier
If this is still reproducible, please add the backtrace for the crash. For more information, please see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
If you can provide the information requested in comment #3, please add it.
Created attachment 108809 [details] GDB trace (In reply to Maik Qualmann from comment #1) > I can not reproduce the crash here. Can you create a GDB backtrace? > > Maik I'm having the same problem as PaulK with a very similar system, Following the link posted by Christoph I'm attachig a file with the text I got using gdb. I hope it helps Thanks
How did you use gdb? With the AppImage the internal gdb must be used, it is called with the option "debug". ./digikam-5.8.0-01-x86-64.appimage debug After the crash, call the backtrace with "bt". Maik
Git commit 8bd0ce861e1ff11daf062f9bfa95bbd7fb42e1b9 by Maik Qualmann. Committed on 12/11/2017 at 21:09. Pushed by mqualmann into branch 'master'. fix crash if Google services authorization fails M +1 -1 googleservices/authorize.cpp https://commits.kde.org/kipi-plugins/8bd0ce861e1ff11daf062f9bfa95bbd7fb42e1b9
The crash is now clear. But why does the authorization fail under the AppImage in Ubuntu? Gilles, can you please create a new AppImage? Maik
yes sure, tomorrow morning... Gilles
Created attachment 108817 [details] appimage with debug comman line argument I'm using this command line: pablo@pablo-ThinkCentre:/usr/bin$ ./digikam-5.7.0-01-x86-64.appimage debug After the crash there is no stack: [Inferior 1 (process 13132) exited with code 0213] (gdb) bt No stack. (gdb) bt No stack. (gdb)
Created attachment 108820 [details] Pop up error SSH Handshake failed I don't mention this earlier but my Google accout whas already authorized with an earlier version of Digikam appimage. With this 5.7.0 version I get a SSH Hadshake error as soon as I enter the Import from Google option. I'm attaching the screen shot on this comment. Pablo
AppImage works under my openSUSE Tumbleweed, but with Ubuntu 17.04 in the virtual machine comes an SSL handshake error. Gilles, I think we're using an internal libssl in AppImage? Maybe too old? But why only under Ubuntu? Maik
The AppImage is build on CentOS 6.9 with all recent updates libopenssl come from the system and the version is 1.0.1e-57: https://centos.pkgs.org/6/centos-x86_64/openssl-1.0.1e-57.el6.x86_64.rpm.html Gilles
I don't have idea why Ubuntu don't work as expected. Here, under Mageia5 or 6, Google Service tool work fine. Gilles
Pablo, do you use Ubuntu on a real machine or in a virtual? Maik
Hi Maik I use ubuntu + Digikam on a real machine. Pablo En 14 de noviembre de 2017 5:35:48 AM Maik Qualmann <bugzilla_noreply@kde.org> escribió: > https://bugs.kde.org/show_bug.cgi?id=385363 > > --- Comment #15 from Maik Qualmann <metzpinguin@gmail.com> --- > Pablo, do you use Ubuntu on a real machine or in a virtual? > > Maik > > -- > You are receiving this mail because: > You are on the CC list for the bug.
same problem on Ubuntu 16.04.3 using the digikam 5.7 appimage.
Please test the pre-release digiKam-5.8.0 AppImage from here: https://files.kde.org/digikam/ Maik
using the 5.8.0 appimage, it does not crash anymore, instead I get a popup with an error message: "An authentication error occurred: SSL handshake failed (6)"
Created attachment 109566 [details] google drive authentication error SSL handshake failed (6) I face the same issue on windows 7 64 bits using digiKam-5.8.0-20171227T203904-Win64.exe
I just tested it on Windows7 and Windows10. I can not reproduce the problem under Windows. Maik
Same issue here with "An authentication error occurred: SSL handshake failed (6)". I use digikam-5.8.0-01-x86-64.appimage (Ubuntu Linux 17.04 4.10.0-42-generic #46-Ubuntu SMP Mon Dec 4 14:38:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux). Strange is that I don't get this error with another laptop with Ubuntu Linux 16.04.03 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux... I tried with deleting all cifing file under .local or .config, but the issue is the same.
This problem only occurs with the AppImage. I have a theory. Which SSL version use Ubuntu 17.04 4.10.0-42 generic and which Ubuntu 16.04.03 4.10.0-42 generic? Maik
Probably the openssl from Centos6 is not updated since a while to build AppImage. As 5.8.0 is out, i will rebuild the whole Centos6 VM from scratch and update all as well before to recompile all Qt5/KF5/DK. Gilles Caulier
On Centos6, openSSL is at 1.0.1e-57. Gilles Caulier
After a full update of Centos6, nothing has changed about the Openssl version installed. Gilles Caulier
My theory is that Google recognizes 2 different versions of SSL and therefore rejects it. Once natively from the browser login to start the authorization and once from the AppImage. As I said, just one theory, because one Ubuntu goes, the other not. Maik
Well the solution is to not copy the ssl version from CentoS6 into the AppImage bundle and let's the system wide library alone. A line to add somewhere here : https://cgit.kde.org/digikam-software-compilation.git/tree/project/bundles/appimage/04-build-appimage.sh#n264 Gilles
I checked ssl version. Output looks similar for Unbuntu 16.04.3 and 17.04: (Ubuntu 17.04) $ openssl version -a OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/usr/lib/ssl" (Ubuntu 16.04.3) $ openssl version -a OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fdebug-prefix-map=/build/openssl-w1gRN6/openssl-1.0.2g=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/usr/lib/ssl"
Are you already authorized in Ubuntu 16.04? If so, does it work if you change your account and log back into the browser? Maik
I respond to my comment 28. As Centos 6.9 still to use openssl 1.0.1 and do not switch to 1.0.2 for security update (strange rule i must admit), i must include last openssl stable in AppImage compilation rule. Planned to 5.9.0 release Gilles Caulier
Maik, Do you confirm that native digiKam using OpenSSL 1.0.2 can to be connected to Google service ? Just to be sure that problem is located with OpenSSL... Gilles Caulier
In my system are 2 libopenssl versions, openssh still needs libopenssl-1.0.2n. Otherwise libopenssl-1.1.0g is used and with the native digiKam version no problem, not even with the AppImage. I have 2 Ubuntu versions in the VM, with one I can confirm the problem, with the other I look again. > Just to be sure that problem is located with OpenSSL... Good question, we only have the error message. QNetworkManager does it all. There are some entries on the web about this problem. Maybe we can disable the certificate check ... but if that is such a good idea? Maik
*** Bug 391734 has been marked as a duplicate of this bug. ***
Thanh, This file still valid with your GSoC 2018 devel branch ? Best Gilles Caulier
Gilles, I'm not sure about this, since I cannot reproduce this on arch linux. So, I guess we should wait for confirmation from user. Thanh.
Git commit dd855b7abedb21b759c374b8b08c448bdb8152dc by Gilles Caulier. Committed on 13/08/2018 at 17:04. Pushed by cgilles into branch 'master'. make symbolic link for libssl.so missing in the bundle to prevent to use system based lib instead FIXED-IN: 6.0.0 M +2 -0 project/bundles/appimage/04-build-appimage.sh https://commits.kde.org/digikam/dd855b7abedb21b759c374b8b08c448bdb8152dc