Further testing leads me to believe that this is probably a Kleopatra / QGpgME / Qt issue. I can pretty reliably reproduce this when using Kleopatra but never have I gotten this with gpgtar only, and I tested it a lot of times.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 6 2019
The difference is between: 0x01035400 and 0x01034600 where 7 blocks of zero bytes are in the broken archive which are not present in the original file.
Kleopatra now shows an error in this case when extracting. So now we only need to fix that this happens at all.
We are currently not aware of any bugs that would prevent the import of valid secret keys.
Thank you very much for the analysis. I'll forward the info.
Mar 5 2019
Mar 4 2019
Ouch indeed. Looks like you run into a "hanging" gpg-agent situation in that case our main background process is blocked and all other processes wait for it to respond and nothing works anymore.
This should never happen and we need to fix it. But so far we have not found a way to reproduce it.
There was indeed a missing dependency. libgpg-error and libassuan were only installed if GPGME was installed, so only if Kleopatra or GPA were selected.
Somehow I thought that storing drafts locally was not only configurable but the default. But you are right, I also can't find a way to change the storage location.
Hi,
sorry for the late reply. I cannot reproduce the issue.
Also reported for Contacts in T4161.
I think that this is the same as T4388 So I'm merging it in.
Regarding 1. That is currently not possible. It is something we should have but which we did not yet implement. I'll move this out into a feature request.
Btw. I'll try to get a new release out this week. In the meantime either downgrade to 3.1.5 or use Kleopatra.
Jep that was part of Gpg4win as Gpg4win needed features / fixes from that version.
Feb 28 2019
Thanks for the report.
Btw. I only noticed this now as I always had "disable-tor" in my config but recently removed it for testing.
Feb 27 2019
I think this can be resolved according to the last comments. We have analyzed it and found that it is not an issue on our side.
I could reproduce the issue and fixed it similar to the code suggested.
The dialog is improved and simplified now.
As a workaround you could also forward the mail to yourself and remove the attachments in the forwarded mail. This would basically work the same as I've described in the previous message.
The next version will have a "decrypt permanently" option. Afterwards you could remove the attachments. Will this help in your use case? You could for example copy the mail into a local folder and remove the attachments then.
Hi, thanks for the report.
I'll try to reproduce it.
(Changing this to invalid as it is more a question and not a bug report per se) You can still comment.
Thanks for the report. Indeed a bug. Will be fixed in the next release.
Feb 26 2019
Feb 22 2019
Feb 21 2019
yikes. Sorry for that one,..
Feb 18 2019
No. Pinentry is always 32 bits for us.
Strange, even if they are missing in the Gpg4win insttall dir they should be picked up from GnuPG which is added to PATH.