Hey. Are there any new regarding this ticket?

What terms in the man page are troublesome for you?

Despite my previous denial, I now think that you are correct: I now think that I did indeed follow a Debian wiki entry on separating the primary key. In my defense it was many years ago :-(. I have now managed to import a primary key, although unfortunately the wrong one.

Just to note that I did import the secret key, but there was no change. I have searched for the term designated box, but I found no hits. Where is this term defined or explained?

Thanks for the prompt reply. I did not explicitly move the primary key offline. Maybe there is something in the default debian configuration that does that?
$GNUPGHOME is pointing to a .gnupg which contains secring.gpg and also a directory private-keys-v1.d/ which contains two keys.

You are keeping your primary secret key offline. You need the primary secret key for most operations because it is required to bind user ids or new subkeys to the primary key. The "pub" indicates that you have only the public part of the primary key. There are several howtos on how to move a key offline and you seem to have followed on of them. The common advise is to have a designated box with the full key (including the primary key) and use that for key maintenance. Of course you can also import the primary secret key.

I should have added, in case it wasn't obvious, that I changed some ids etc in the report just to protect precise details.

Similar issue with ntbtls:

I reviewed the multibyte handling in GnuPG and you are right, there is a general problem because we use ReadConsoleA and basically GetCommandLineA, so there is no way for multibyte input unless a parameter file is used. Output is also broken, but that is easier to fix iff the input case has been fixed.

FWIW:
The first config.log is from a gnutls build.
The second for libassuan 2.5.3 and has been configured:

./configure --enable-shared --prefix=/var/tmp --libdir=/var/tmp/lib64

Libassuan 2.5.3 has a similar problem:

Changes backported to 2.2

Hello,
I've opened T4395 for this to keep better track of it as this task was about another issue.

Hi，aheinecke。my kleopatra version is "kleopatra Version 3.1.4-gpg4win-3.1.5".and when change expiry date, i enter a wrong passphrase or choose "cancle". it shows successfully. what can i do for solve this question. thanks.

And attached is a test key.

Ok here is the output:

C:\Users\croll>gpg --import "Desktop\Charles Rollins.asc"
gpg: key C7EE3D25FF2E5EF5: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: key C7EE3D25FF2E5EF5: failed to re-lookup public key
gpg: key C7EE3D25FF2E5EF5: public key "Charles Rollins
<crollinsphoto@gmail.com>" imported
gpg: Total number processed: 2
gpg: w/o user IDs: 1
gpg: imported: 1
gpg: secret keys read: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 4 signed: 9 trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1 valid: 9 signed: 0 trust: 1-, 0q, 0n, 0m, 8f, 0u
gpg: next trustdb check due at 2019-11-05

C:\Users\croll>

What is meant by missing self signature? I signed it before exporting it.

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.

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.

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.

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.

GPGME 1.12.1-beta43 is nowhere near the current master. Current is around 1.12.1-beta130 (or above) and beta 43 would've been months ago, probably early November or late October.

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?

i can t decrypt message!!!

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

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.

Btw. I only noticed this now as I always had "disable-tor" in my config but recently removed it for testing.

I could reproduce the issue and fixed it similar to the code suggested.

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.

Builds fine now with GCC 9. Thanks for looking into this so quickly.

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.

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.

Fixed in master.

Thanks for your report.
I think that your patch is too generous to run HMAC even if fips_mode is not enabled; Simply, we can stop calling integrity check when fips_mode is not active.

I could reproduce the problem (by chance) now, because I started a VM I didn't use for a while:

This is caused by the encoding of file in windows. If we directly redirect the stdout to file, windows encodes the file as CRLF+UCSE LE BOM but linux encodes it as LF+UTF-8. To make the file work, I just need to run dos2unix to convert the encoding. Hope it help someone having similar issue.

Original issue (of pinentry-curses, which should be killed by CTRL-C) is related to T2011: gnupg should notify cancellation of its operation to gpg-agent to kill pinentry, I suppose. It is fixed in master and testing.
I don't know about the second one with pinentry-tty.

Fixed in master.

No. Pinentry is always 32 bits for us.

Could it be possible that it's a 32/64 bit issue?

Is this with the /MINIMAL flag?