Talk:GnuPG

System login with gnupg smartcard (yubikey, p-card, rsa token, etc)

gnupg with poldi can be used for system login. There is a thread asking whether it is possible to use gpg for system login. A new tip section explaining gnupg smartcard for logging into Arch Linux system is a nice addition here.

Alive4ever (talk) 02:27, 4 August 2016 (UTC)

User configuration files not created

Per the wiki, it states, "You will find skeleton files in /usr/share/gnupg. These files are copied to ~/.gnupg the first time gpg is run if they do not exist there."

I could very well be doing something wrong so I'd ask that this could be verified. If we need to copy skel configuration files, it should be clearly explained in the wiki shouldn't it?

I was unable to import public keys until I manually created a blank ~/.gnupg/gpg.conf with just keyserver pgp.mit.edu in it.

I also found this when searching for info, https://manned.org/gpgv2/2862e42d. It states: There are no configuration files and only a few options are implemented.

NuSkool (talk) 04:09, 26 September 2016 (UTC)

On the same topic but on a different note, update GnuPG#Configuration_files to remove out of date warning and add the following informtion:

1) ~/.gnupg/gpg.conf and ~/.gnupg/dirmngr.conf are not created by default. So, the user can create them to implement the changes.

2) global config file is located at /etc/gnupg/gpgconf.conf shown by command gpgconf --list-config. This is also not created by default. The example file is

at /usr/share/doc/gnupg/examples/gpgconf.conf

--RaZorr (talk) 12:51, 16 January 2022 (UTC)

I've used gpg and I don't have the configuration files. The wiki is wrong. Pound Hash (talk)

I am having difficulty corroborating the existence of this functionality. There is no "default" gpg.conf in the GnuPG repository, and I'm not sure if it even makes sense to have one. This file is for overriding defaults. For instance, this is what mine looks like:

gnupg.conf

no-default-keyring
keyring keyring-path
default-key default-key

It shouldn't be a complicated configuration file, just command line options that you want to use all the time. dirmngr.conf is exactly the same way, as far as I can tell. So, RaZorr got it totally right with 1). With 2), though, /etc/gnupg/gpgconf.conf is actually not the global version of ~/.gnupg/gpg.conf. /etc/gnupg/gpgconf.conf is a "legacy mechanism" for setting up defaults using the gpgconf progrma. The modern way for configuring system-wide GnuPG defaults is ~/.gnupg/gpg.conf's actual global analog: /etc/gnupg/gpg.conf, which was introduced in 2020 [1].

I gave a shot at fixing this part of the page. Thanks, CodingKoopa (talk) 08:21, 20 May 2022 (UTC)

I am trying to use /etc/gnupg/gpg.conf But seems like it is not respected by gpg at all. Doesn't matter what I put there, it just doesn't effect. Arash (talk) 18:06, 10 January 2024 (UTC)

The problem was from setting permission of /etc/gnupg/ files to 600, making them unreadable to user's gpg. Changing file permissions back to 644 resolved the issue.
Arash (talk) 18:43, 10 January 2024 (UTC)

Recommendation to add

By default, no skeleton files exist (as mentioned above) but in my case the lack of a dirmngr.conf meant that any --recv-keys failed with useful(?) errors like "gpg: keyserver receive failed: Server indicated a failure" or "gpg: error searching keyserver: Server indicated a failure". Route to get here was via makepkg, and so I skipped all the installation steps etc since gpg was already installed and went straight for a recv.

   echo > $HOME/.gnupg/dirmngr.conf 'standard-resolver'

Beepboo (talk) 17:09, 22 March 2020 (UTC)

also requires to restart dirmngr.service Louson (talk) 13:32, 25 April 2022 (UTC)

but the problem is probably on the /etc/resolv.conf file. Are you using systemd-resolved ? Then check Systemd-resolved#DNS Louson (talk) 13:46, 25 April 2022 (UTC)

Encountered this issue today. GnuPG uses /etc/resolv.conf, but by default this file is empty when using Systemd-resolved#DNS. Gnailuy (talk) 16:03, 24 July 2024 (UTC)

As the link you gave shows, it shouldn't be empty because you were supposed to configure it. That's Arch. Scimmia (talk) 16:44, 24 July 2024 (UTC)

Oh, yes, I missed the Systemd-resolved configuration for this new install. Network worked until I started to use GPG.

Thanks. Gnailuy (talk) 02:59, 25 July 2024 (UTC)

A comment on provided code snippet

The test from Set_SSH_AUTH_SOCK :

   [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]

would probably always fail, since [2] sets gnupg_SSH_AUTH_SOCK_by to the process id of gpg-agent, and the line above tests it for the process id of the bash process.

Therefore,

   export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" 

will probably get executed every time. However, it most likely wouldn't break anything since at worst it will reset SSH_AUTH_SOCK to the same value.

—This unsigned comment is by Thread13 (talk) 11:16, 1 May 2021‎ (UTC). Please sign your posts with ~~~~!

Qouting the the note there

Note: The test involving the gnupg_SSH_AUTH_SOCK_by variable is for the case where the agent is started as gpg-agent --daemon /bin/sh, in which case the shell inherits the SSH_AUTH_SOCK variable from the parent, gpg-agent [10]

Doesn't that address Thread13 comment?

Regid (talk) 02:59, 23 November 2024 (UTC)

Invalid IPC response and Inappropriate ioctl for device

I solved this problem simply by removing an # inside /etc/pinentry/preexec enabling the desired option and then setting /usr/bin/pinentry as default. Pavlov (talk) 15:19, 2 May 2021 (UTC)

Another suggestion for troubleshooting automatic key fetching from keyservers in case that SRV lookup fails

If the port is not explicitly stated, than GnuPG will try to use a DNS lookup using SRV [1]. This may fail due to various reasons, so troubleshooting will be to explicitly set the keyservers with the ports, e.g. in ~/.gnupg/dirmngr.conf (or where appropriate) keyserver hkps://keyserver.ubuntu.com:80 instead of just keyserver hkps://keyserver.ubuntu.com [1] https://dev.gnupg.org/rGc2cbe2f87c480c62239dc4c2cbb352acd98cd267 --Tobias.predel (talk) 10:09, 10 June 2022 (UTC)

pgp.mit.edu is not resolving

pgp.mit.edu is not resolving, but is used many times within this documenation. Anyone have an ideas on an alternative? Jahway603 (talk) 17:11, 9 March 2023 (UTC)!

At the time of this writing, it is resolvable here as an alias (CNAME) to cryptonomicon.mit.edu, with an address of 18.9.60.141. Can it be your query ignored the possibility for a CNAME record? Regid (talk) 11:22, 24 January 2024 (UTC)

What about setting ForwardAgent yes as shown in OpenSSH#Agent forwarding?

I tested the gpg-agent forwarding and the OpenSSH ForwardAgent yes options. I am able to forward the use of my gpg key on my hardware key with the former, but it doesn't work with the latter. Seodisparate (talk) 12:23, 24 June 2023 (UTC)

Global configuration files should have 644 permission

Setting permission of global configuration files at /etc/gnupg/ to 600 make them unreadable for user's GPG process and thus makes them completely ineffective, unless user invoke gpg as root which is the owner of the files; which in turn is not the proper way to use the gpg command. Arash (talk) 18:30, 10 January 2024 (UTC)

I guess you are right, yet this looks to me irrelevant. It looks to me irrelevant since my understanding of GnuPG#Configuration is 0600 is referring to files under ~/.gnupg/, not to files under /etc/gnupg/. Regid (talk) 11:39, 24 January 2024 (UTC)

Global GPG config special flags

Even though not well documented, The global GPG config file (and other files in the /etc/gnupg/ directory) can have 3 special flags.[3]

They are [force]To enforce an option to system's gpg users, [-force] To force disable an option and [ignore] to ignore a flag if it is used by users.

These flags can't be used in the user's gnuhomedir config files, and are specific to global config files.

Arash (talk) 13:21, 11 January 2024 (UTC)

Care must be taken when setting system-wide options in /etc/gnupg/ files; particularly, one has to be extra careful when using [force],[-force] and [ignore] options.

Any flag used in these files, will affect operation of all software programs which are using GPG internally, systemwide. Namely, pacman-key.

As an example, changing trust-model option to any mode other than pgp in /etc/gnupg/gpg.conf, or setting use-keyboxd in /etc/gnupg/common.conf will stop pacman-key and consequently pacman from functioning properly.

Arash (talk) 21:19, 12 January 2024 (UTC)

Three Outdated "See also" articles

Yesterday, I putted time reading additional documentations introduced in this section.

Three of them are pretty old, and their contents are not true (At least in details) or accurate any more.

Alan Eliasen's GPG Tutorial
gpg.conf recommendations and best practices
A more comprehensive gpg Tutorial
Arash (talk) 13:37, 11 January 2024 (UTC)

Using new "keyboxd" for keyring instead of "pubring.kbx"

A section can be added to this article talking about it. Or, At least, it's good to be mentioned in some part of this document.

As per recommendation of GnuPG[4], one can use key database daemon (keyboxd), with SQLite database, instead of keyring.kbx file for storing public keys.

This is currently the default since version 2.4.1 and will be in effect for any fresh home directory.
Also, this can be enabled with use-keyboxd option in the common.conf file (One has to be created if it does not exist yet.) for older home directories.

For a fresh keyring, nothing needs to be done. But for a current keyring, they have to be imported to the new database.

Nevertheless, it's as simple as:

gpg --export --export-options backup  > allkeys.gpg
gpgsm --export --armor                > allcerts.gpg

To export current public keys. And:

gpg --import --import-options restore < allkeys.gpg
gpgsm --import                        < allcerts.crt

To import them to the new keyboxd, then adding use-keyboxd option to the common.conf to enable the new keyring format.

However, It may not be compatible with software programs that expect GPG to have a pubring.kbx to import it.[5] Even though it can be created easily in a reverse process in case.

Arash (talk) 01:39, 12 January 2024 (UTC)

Which keyserver or keyservers are recommeneded?

Section 3.5.3 Keyservers mentions three keyservers, each with slightly different capabilities. I would find it helpful if a brief explanation (for keyserver novices) were included with a recommendation, of which ones to use, in what order, and why. vgivanovic (talk) 18:09, 15 January 2024 (UTC)

Well, 3 distinct differences between Ubuntu Keyserver and {Mailvelope Keyserver, keys.openpgp.org} are already mentioned at GnuPG#Key servers: federated or centralized, verification and deletion. According to Mailveleope, deletion adds to compliance with the EU Data protection Directive. Mail verification can lead to spamming. Absence of Web of Trust is a matter of better privacy while makes it more difficult to trust the key holder. Mailvelope seems to have several related open source projects. I did not check about the source of the other two key servers. Regid (talk) 12:31, 24 January 2024 (UTC)

Pinentry's DBus Secret Service API disabled when running under KDE

Since pinentry version 1.3.0 (relevant commit), when running under KDE, the DBus Secret Service API integration is forcefully disabled, regardless of the DBus Secret Service backend in use (KWallet or otherwise).

There exists an upstream commit to override this behavior through the presence of an environment variable. While not yet present in a release, a workaround for this issue would be to install the pinentry-git aur package, and setting the `PINENTRY_KDE_USE_WALLET` environment variable system-wide or within the systemd gpg-agent user service's unit file Capito27 (talk) 09:41, 23 April 2024 (UTC)

Organization of shared pcscd access

The GnuPG#Shared access with pcscd section has some text beneath it which seems unrelated to the other child sections:

• GnuPG#Multi applet smart cards
• GnuPG#Using a smart card on a remote client

Namely, there's discussion specifically about the pcsc-shared option. As it's currently organized, the articles read (to me, anyway) as if configuring pcsc-shared is a prerequisite for the nested articles.

I don't believe that this is the case, though if someone else knows better I'd gladly appreciate the feedback.

My suggestion is one of the following, in order of preference:

1. Move the L4 sections to L3 sections, to be on the same level as the other articles beneath 7.2
2. Break out the pcsc-shared description under a separate section under 7.2.2, so that it doesn't seem like it is required for 7.2.2.1 and 7.2.2.2
3. Do nothing

SMendon (talk) 19:08, 4 July 2024 (UTC)

Yes, I agree your preferred (1.) is the best. I think they could be reordered without change. As an aside GnuPG#Multi applet smart cards will be good at L3 to point to the new gpg-card features to configure them (e.g. yubikey). --Indigo (talk) 21:15, 4 July 2024 (UTC)