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?

Strange, even if they are missing in the Gpg4win insttall dir they should be picked up from GnuPG which is added to PATH.

Libdns is not our own code and our intention was to keep it in sync with upstream. However, after some initial success the upstream author lost interest. We now consider to rework the code to remove a bit of the more creative use of C99 and maybe even get rid of some of the used C99 features (gnupg is mainly C90 with some exceptions).

I don't think code page is the problem per se though.

0.10.0

Which version of gpa is that?

Please try "gpg --quick-gen-key" which takes the user-id on the command line - that uses a different code path.

I think we might accept this with low priority. As this is an unusual way to create a key.

I have updated Pinentry’s configure script to support the --disable-doc option, as it is indeed supported in other GnuPG components.

Patch applied, thanks.

Patch applied, thanks.

So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.

I don't think that we are going to change this. All data is utf-8 including the *conf files.

Is a PR to add it to the website welcome? Not sure that I'll get around to it, but in case someone else is interested - I linked here from those stackoverflow pages.

See also T4013 which is about ed25519 key support

It is in the tarball:

doc/DETAILS

and for example Debian installs it as /usr/share/doc/gnupg/DETAILS.gz. Check out the first section "Format of the colon listings". Or use GPGME which provides C, C++, Python and JSON bindings. Sorry, it never made it to the website.

@werner where is this now documented? I can't find it.

@kristianf we talked about this on Saturday evening. Would you be so kind and have a quick look at the problem with the hu server?

Okay, I see the problem. The microsoft toolchain is more picky about de-facto standard use patterns with common blocks and the author of that code was not ware of this. Thanks for reporting, will be fixed in the next release.

This is not about a function, but about the variable _gpgrt_functions_w32_pollable. And this is not about exporting the variable from the library, but about declaring it as extern in gpgrt-int.h, so that gpgrt-int.h can be included in multiple translation units without defining the variable in each.

This function is not exported on purposes. Even the name of the header file indicates that tis is internal. External, that is public functions of the API, are defined gpgrt.h and only made externally visible by including them in the .def file. This has not been done and so I don't understand your bug report.

Hi Werner and thanks for looking into this.

According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.

No... In this situation, my atachment is a rar file

Interesting. Thanks for reporting this. This happened in the past because images had a "content-id" (so they were marked to be an embedded image) but were not really embedded. I did not have a very good fix then because it is hard for us to detect (easy for Outlook itself though) so there might be more special cases where this happens.

fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.

That is a very interesting problem that we did not have on our radar.