Actually I would like to remove the option to install gpg4win at non-standard places because this is somewhat troublesome. However some users rely on this and thus we better don't remove i.

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.

ı dont understand can you explain me more specific? which file name ? when ı select the Tor installer gpg cant decrypt it not signature file

Download the corresponding tor signature file. Then enter that file name.

Dear Werner!

Dear Werner!

To change the expiration date, I would suggest to use

Yes, with current gnupg it works w/o problems. Well, unless systemd decided to remove the directory. There is a loginctl(1) way to avoid this.

Also I suppose the 2.1.20 version above is typo and 2.2.20 is actually meant.

Can you please clarify? Let's assume I am using current gnupg version (2.2.20) and /run/user/$UID exists. Everything should work seamlessly, should it?

You are still using the old way of having the sockets in ${GNUPGHOME:-~/.gnupg}. Since 2.2.13 we use

That smells very much like an old and insecure version 3 key. We don't allow them anymore - use gpg 1 to decrypt old material but never use that key to sign stuff or give it to others to encrypt to you. It is just too weak.

keyserver-URL needs to be replaced with with a keyserver URL, like

hkps://hkps.pool.sks-keyservers.net

In my particular case, I want to find out if an email address has a publickey associated to it that is publically available anywhere. I do not want to import the key automatically. I used to use this command:

--auto-key-retrieves tries to find a key when verifying a signature. --locate-key however does the same as what -r does and locates a key for further use. If you don't what that, don't include a key discovery mechanism in the the auto-key-locate like (wkd in this case, which is anyway the default).

Older version of GnuPG had a rare bug in the keyring update code.

[When changing a bug to a possible FAQ item it should be resolved and not marked as invalid]

All output of Assuan data lines is percent escaped. That is obvious because it is a line based format. You need to unescape it. Either use command line option

--decode

in-line command

/decode

or use

/datafile NAME

to write to a file.

This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.

Do not use this legacy debug stuff. Use --debug CATEGORY. For example

Users keep showing up in our support, confused by this inconsistency. This problem continues in 2020. What's holding this back?

No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.

First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.

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.

There has been some progress here. At least we no longer use "passphrase" in new code. We still have not yet replaced all old occurances.

I contacted Microsoft Security Response Center (MSRC) in regard to this matter. They confirmed the failed PGP key verification, but have not yet any explanation for that.

What are MS doing when they get it right, though? I'd look at the differences between those two to identify what they've messed up here.

Thanks. The mail is a standard, non-crypto mail with one attachment. That attachment is a TNEF file which has according to ytnef(1) just one file. That file has the name gpgolPGP.dat and contains a clearsigned message.

Sure, I zipped the eml which failed and I´ll send it by e-mail to you

Is it possible that you upload or send me a copy of such a mail (wk gnupg.org)? ZIP or tar the eml file and send it in an encrypted mail to me to make sure it won't be modified on the transport.

I checked my mails in detail, and I can confirm that the error occurs only with "Microsoft security update releases". Indeed "Microsoft security advisory notification" and "Microsoft security update summary for..." will be verified correctly.

I agree. It also happens to me. But only with mails coming from "Microsoft security update releases". Mails coming form "Microsoft security advisory notification" and Microsoft security update summary for..." are ok and are signed by the same key. It could be some trouble in MS automated email treatment.

So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

BTW, you now need to use --rfc2440 to create a non-mdc message for testing.

It's nice. Although for now I've only added a message in the legacy_cipher_nomdc case:

I justed commited some gadgets to gpgme which might be helpful But please show warnings etc before you use that new option.

You are right in that enigmail uses no-auto-check-trustdb

As far as I understand your comment there is already a timeout of 15s per connection. But as you wrote, it doesn't fit all cases. In my case, gpg.exe just stayed open indefinitely.

man dirmngr

In T3714#109752, @werner wrote:

I have not checked whether we make this available in the GPGME API

There can't be an MDC warning if MDC is not used ;-)