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.
Thanks for that summary.
Wed, Feb 13
Tue, Feb 12
Mon, Feb 11
Released 2.5.3 today:
- Worked on PIV support
Sat, Feb 9
I don't think that we are going to change this. All data is utf-8 including the *conf files.
Sure, but lets use that ticket for this. if you have another topic, feel free to open another ticket.
Fri, Feb 8
Thu, Feb 7
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.
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.
Despite that I created this task, I am still not not convinced that removing the term passphrase is a good idea. If we do this in gnupg we would need to change all strings to make it clear that the passphrase is used to protect one's own key and has nothing to do with encryption etc. In fact the term PIN would be better because it is common knowledge that you use a PIN to get access to something you own. There would be less confusion on the purpose of the passphrase. Sure PIN is usually considered to be a number. However my bank allows a string to be used as, what they call, PIN.
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.
Fri, Feb 1
Thu, Jan 31
Wed, Jan 30
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.
Tue, Jan 29