I do have a with a symmetric cypher at a 64bit RH system encrypted PDF file, which I tried to open here a t a 32bit stable Gentoo Linux via Dolphin and click with the right mouse button onto Actions -> "View file decrypted". KGpg open its window, 1 of the 4 cores of the CPU goes at maximum speed and nothing happens till killling kgpg. Decrypting the PDF file itself and showing the content with okular works fine however. The issue might be (at least partially) related to the PDF content too b/c printing a "Hello World" to cups-pdf under Gentoo, encrypting the file and doing then the same steps as above works fine (although the content of the decrypted PDF is shown in KGpg's window instead within okular). The PDF file is somehow confidential, therefore here just the back traces of KGpg. Reproducible: Always
Created attachment 85650 [details] gdb kgpg -n -batch -ex 'bt' `pgrep kgpg` > bt.txt
Created attachment 85651 [details] gdb kgpg -n -batch -ex 'bt full' `pgrep kgpg` > bt-full.txt
Please add some kDebug() lines in gpgproc.cpp in "int GPGProc::readln(QString &line, const bool colons)" to see if it getting new input data there or if it just looping on the same stuff over and over again.
Well, with this changes : int GPGProc::readln(QString &line, const bool colons) { QByteArray a; kDebug(2100) << "miau"; if (!readLineStandardOutput(&a)) return -1; kDebug(2100) << "wauwau"; line = recode(a, colons, m_codec); kDebug(2100) << "ia"; return line.length(); } these log lines are the last : ... kgpg(24814) KGpgTransactionPrivate::slotReadReady: KGpgDecrypt(0x88b9928) "�3������0�#b8nG kgpg(24814) GPGProc::readln: miau kgpg(24814) GPGProc::readln: wauwau kgpg(24814) GPGProc::readln: ia kgpg(24814) KGpgTransactionPrivate::slotReadReady: KGpgDecrypt(0x88b9928) "��:�,�j�m$�����1#;0���w@�Ҟ��'���p���?���z�L=N\��$�H�gV|gQ(��x{�ʥ kgpg(24814) GPGProc::readln: miau kgpg(24814) GPGProc::readln: wauwau kgpg(24814) GPGProc::readln: ia kgpg(24814) KGpgTransactionPrivate::slotReadReady: KGpgDecrypt(0x88b9928) "#l�XZM�m�<l+�{�▒a����]�n�bY7���Gٛ�,��n�%�b▒��c�-�.Wݘz�uh��J�r-6�K��jm_��H��ÇQ�▒r����Ki�!4$w`�S!Wm�C��]��c 5,��bX �MA3���!�B����� kgpg(24814) GPGProc::readln: miau kgpg(24814) GPGProc::readln: wauwau kgpg(24814) GPGProc::readln: ia ��8���>���/�P��W��[O-���(onPrivam�wZ�bU�W��O��q|��e�IIzܤ�4▒����b�l��t��6%Ȳ��.#i��m�v!��7W�vMb���v���\�O\�n��DwG�daAG�����������E2�2��う���� o��M%x��7���3ߤ���o�r��eӿ��L/=wvٚ�0�t8��9А��*�J�/9p�c�A8�lW�!�[��!t V�V��M�:c�1 E'��A����Z2��q�Nk ��'I(���1@l[�)Y��t#�&��J��k$��J� �K ~nr'���=̖�ϫ�HjuZ��WT��3ɶD5y��<�������J!P��j-�,3W�^�JR4
sry , here it holds off : kgpg(24814) GPGProc::readln: miau kgpg(24814) GPGProc::readln: wauwau
And here's the culprit given this snippet : while ((pos = a.indexOf("\\x", pos)) >= 0) { kDebug(2100) << "wauwau" << pos; if (pos > a.length() - 4) break; I do get tons of : ... gpg(5028) GPGProc::recode: wauwau 30 kgpg(5028) GPGProc::recode: wauwau 30 kgpg(5028) GPGProc::recode: wauwau 30 ... as soon as I try to open the encrypted PDF file
Hhm, and finally : kDebug(2100) << "miau" << ok << n[0] << n[1]; if (!ok) continue; gives kgpg(8190) GPGProc::recode: wauwau 30 kgpg(8190) GPGProc::recode: miau false kgpg(8190) GPGProc::recode: wauwau 30 kgpg(8190) GPGProc::recode: miau false ...
Created attachment 85697 [details] Prevent endless loop This will likely create garbage output, as those transaction classes probably don't work well for binary data. But it should at least prevent the endless loop.
(In reply to comment #8) > Created attachment 85697 [details] > Prevent endless loop > > This will likely create garbage output, as those transaction classes > probably don't work well for binary data. But it should at least prevent the > endless loop. yep - now the Kgpg window appears immediately and the first 5 lines of the PDF files looks valid, but if I do save the output to a file, that okular does display that as an empty 6-page document.
Git commit 72b60a982798825f474bd739d0edc2ba0ba6cefb by Rolf Eike Beer. Committed on 22/03/2014 at 22:10. Pushed by dakon into branch 'KDE/4.12'. fix endless loop if \x is not followed by 2 valid hex chars Those transactions do not work well if the data is binary, but at least the process will not get stuck in an endless loop any more. M +4 -1 gpgproc.cpp http://commits.kde.org/kgpg/72b60a982798825f474bd739d0edc2ba0ba6cefb
Created attachment 85700 [details] base64 < x.pdf | head -n 5 > 5.base64 attached is the output of the encodced file of : $> base64 < x.pdf | head -n 5 > 5.base64 Maybe it helps you to improve a heuristic rule ? Just decode it with $>base64 -d < 5.base64
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!