The Libgcrypt version you are using has not been build from git or a released tarballs. Only with a released tarball you would get no suffix. With git bou will see a -betaNNNN suffix.

Because a user in https://mstdn.social/deck/@GnuPG/113011825339406300 did read the documentation, I had a look in the documentation and in other public definitions (e.g. https://www.gnu.org/software/tar/manual/html_node/Formats.html#Formats) and I can understand the questions of the user.

gpgtar is compatible to PGP Desktop's format which they call ZIP. This is technically ustar with the most common extensions. Don't let us go into yet another TAR format discussion.

Good idea. Done for master and gnupg24

Right, thanks for the information. Might I suggest printing a warning when --keyring is given?

The --keyring option is deprecated and does not work at all if the keyboxd is used. This is the default for a new GnuPG 2.4 installation.

You may want to write gnupg-users@gnupg.org to tell about this tool. That seems to be a better place with a larger audience. Or you add it to wiki.gnupg.org.

I did in fact check --status-fd before, but I'm not sure whether it gives me the information I wanted.

Please use the --status-fd interface. This yields all the info you need. An exit code is not distinct enough for such purpose and you need to check the status lines in any case. For scripting gpgme-tool or gpgme-json might be useful as well because they do all the nitty-gritty parts of using gpg correctly

In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

Ah well, Kleopatra has a GUI to set the keyserver - that is probably easier to use.

Thanks for the explanation. I understand gnupg-w32 is mainly for installing the command line component, yet adding a context menu for a specific file type is just as simple as importing a reg file like:

It is related in the following way:
The Gpg4win installer creates these context menu actions through the component GpgEX.
The Gpg4win installer does not support Windows XP anymore.

What I need is exactly ikloecker described on Linux. The point is NSIS installer gnupg-w32-2.2.27_20210111.exe (and versions above, I am sure) do not create context menu shortcut. Windows XP is not the point. Same on another Windows 7 machine. Do you need I find another windows 10 machine to test? I think it's easier to check whether the installer has that feature or not.

No support for Windows XP anymore.

Sorry, I should clarify that I am using the windows installer
gnupg-w32-2.2.27_20210111.exe on WindowsXpSp3. The installer do not create
any context menu since I use it. I use Gnupg with Enigmail in Thunderbird,
so Gpg4win is not preferred.

This is a hard to solve problem in the NSIS installer: If you accidently started more than one installer they may both register files for update at the next restart. Now after the restart the file which is to be renamed does not anymore exist and thus a component or even library is not available. In this case it is GpgEX, the explorer plugin.

gpg verifies the content of the file and not its meta data (file name). Thus an empty file is identical to a non-existing file. The OpenPGP protocol does not allow to distinguish between a detached signature and an embedded signature if you sign an empty file.

Okay, I close this as a keyserver infrastructure problem. Feel free tore-open if you get other infos.

So let's close this task.

Take care: It is not clear whether you may use a [C} subkey for certification. GnuPG currently accepts this but the RFC can also be read as primary keys needs to to do the certification.

For signing (aka certifying) another key you need a (sub)key with the "certify" capability. Your signing subkey can only be used for signing data but not for certifying keys. This isn't specific to gpgme. See https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21.

Yes, you need the secret part of the primary key. gpgme has this info but it is easy to miss. Even our gpgme/tests/run-keylist.c debug tool did not show it directly. I modified it to make this more clear, see the latest gpgme commit. Here is an example for my key:

$ ./run-keylist --verbose --with-secret  63113AE866587D0A
keyid   : 63113AE866587D0A
caps    : esc
flags   : secret
upd     : 0 (0)
fpr    0: AEA84EDCF01AD86C4701C85C63113AE866587D0A
grip   0: CE5C1F1B8C96F1A078A2D1932EEE738A854ED976
curve  0: ed25519
caps   0: sc
flags  0:
fpr    1: E05BA20ED4F17768613B03C53CD7B3A055039224
grip   1: 7A1E3130C9CBDBF203A0AD8E186D9C511D5019FF
curve  1: cv25519
caps   1: e
flags  1: secret
fpr    2: 8777461F2A074EBC480D359419CC1C9E085B107A
grip   2: FF35C6E765F440145095750DC97D43D496C5ABEA
curve  2: ed25519
caps   2: s
flags  2: secret

The curve is not defined to be used for ECDH (encryption); in fact it should in general only be used with the EdDSA
algorithm. You need to use "Key-Type: eddsa". Note that the EdDSA signing algorithm is different than the commonly used ECDSA signing algorithm.

Thanks for the quick response Werner. I knew I could use it with quick-gen-key and I’ve updated my config file to have it as default.
But, just for my understanding, is there a reason ed25519 cannot be used with full-gen-key and gen-key in batch mode?

You can't use ecdh with ed25519.

No Apache - No Default charset per suffix. The version for browsers is the HTML version.

The surprising thing is that it works at all. I wouldn't be surprised if certain would simply reject it as "not a pdf" given that the "%PDF-1.x" marker isn't at the beginning.

--clearsign may only be used for plain text documents due to line ending conversion etc.

It is possible to disable the mlock thingy and if that is not wanted the application should be modified to be suid(root) during Libgcrypt initialization - this is actually how we handle this in GnuPG. Or maybe I don't understand the bug described here. It seems to be more of a support question.

The specs might just want to say that it just expects the wildcard to be broken, not that it expects an empty record.

Than put something into the TXT - it does not matter and is only used to break the wildcard.

Cloudflare doesn't seem to allow empty DNS TXT records...

From the specs:

No more info was provided.