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.
Tue, Feb 19
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.
Mon, Feb 18
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).
Sat, Feb 16
I don't think encoding is the problem though.
Fri, Feb 15
Thu, Feb 14
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.
Wed, Feb 13
Tue, Feb 12
Mon, Feb 11
I think we might accept this with low priority. As this is an unusual way to create a key.
Sun, Feb 10
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.
Sat, Feb 9
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.
Fri, Feb 8
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.
Wed, Feb 6
See also T4013 which is about ed25519 key support
Tue, Feb 5
It is in the tarball:
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.
Mon, Feb 4
@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.
Sat, Feb 2
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.