Does gpa show that your key has a public and secret part?
Open a command shell (cmd.exe) and enter: gpg -v -K
This list all you secret keys - Do you see it something like
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 1 2019
Feb 28 2019
I have everything on the same machine until last week everything worked now does not allow me to decrypt only that my pc had a forced shutdown of windows I would not have been the one I tried to uninstall and reinstall pgp4win yesterday but the problem remains
Okay, this is the latest released version. I now wonder what you mean by version 1.12.1-beta43. This sounds like our current development version of the GPGME library, right? How did you install this software? Is it from Gpg4win or did you build it from source?
You don't have the secret key part matching the public key part which was used to encrypt the message. You must decrypt on the same machine and account on which you created the key. Or you need to copy the secret key from the first machine to your current machine. GPA as export and import options for this. Please read the Gpg4win compendium to learn about the details
Looking at other threads I found the problem in some .lock file in my gnupg directory. One of them was locked by a running process and I was not able to delete. So I opened up task manager and I had dozens of gnupg related processes running. I killed all of them and removed any .lock file.
This way Kleopatra started again but the certificate above (aruba) was not present in the imported ones. And, of course, I'm not going to import it anymore, will use my sixt sense to trust certificates...
The exact file that created the lock is attached
I zipped it to avoid an unintended import that kills Kleopatra.
The only action I can do is quit the program telling it to stop the background actvity, but I cannot use it anymore...
Ouch, worse problem here. After closing kleopatra telling it to stop doing whatever it was, I restarted the application and now it's stuck in "Loading certificate cache"
The certificate was defintely missing the tag lines, thanks. I also tried opening the certificate from that page (Windows has no problems without the tag lines) and exporting it explicitly as base64, and the output file is fine.
The problem is that the import now seems to go well, but no certificate is imported at all. I tried several times and the import box just closes after selecting the file.
I tried to close Kleopatra and it says there are ongoing background operations. At least 15 mins passed between the import and the closing tentative.
Actually, it is stuck doing something.
Thanks for the report.
The other option would also work for me. Thank you!
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 agree! THANKS
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.
We also need to fix for encryption and signature in CSR.
Feb 26 2019
Builds fine now with GCC 9. Thanks for looking into this so quickly.
Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.
Fixed in master, by removing use of compound literals. Compound literals are not portable feature (even for C99 code), so, it's good to avoid when we can.
Still dns.c uses C99 features of struct initializer with name.
Feb 25 2019
Will be released with 1.12.1
Thank you!
Please see the section 'Selecting Signers'.
When did you last try to login to dev.gnupg.org? What browser and OS are you using. Did you try with this account?
Please describe in more detail what you did so that we can replicate this. We also need to know your OS and the GnuPG version.
Thanks, applied to GnuPG 2.2, master, and libgpg-error.
@werner Looks like recpstring is only supported for encrypt and encrypt+sign, but not just for signing. Is there a way to specify the subkey to use when signing?