Apply Legacy GnuPG Defaults to Existing User Homes Safely

You will finish with a controlled way to apply the legacy GnuPG defaults file to existing user configuration, without mistaking it for a permanent enforcement mechanism. These examples use GnuPG 2.4.4 from the installed gnupg-utils package, version 2.4.4-2ubuntu17.6.

Allow about fifteen minutes, plus a maintenance window if several users or services rely on GnuPG. You need a root shell, a readable copy of the policy you intend to use, and a list of affected users. Do not run the wrapper casually: it writes configuration files in multiple users' GnuPG home directories.

1. Confirm the installed command

Start with read-only checks. These do not need elevated privileges unless your system restricts access to the binary or package database:

$ command -v applygnupgdefaults
/usr/sbin/applygnupgdefaults
$ dpkg-query -W -f='${Package} ${Version}\n' gnupg-utils
gnupg-utils 2.4.4-2ubuntu17.6

The local manual describes this program as a legacy script. It is a wrapper around gpgconf --apply-defaults, run for all real users who already have a GnuPG home directory. It is not a general GnuPG initialisation command and it does not create a home directory for every account.

Checkpoint: confirm that the command path and package version match the system you are about to change. If they do not, stop and read that host's installed manual before copying the examples.

2. Understand what policy file the wrapper consumes

The wrapper passes the apply-defaults operation to gpgconf. The operation takes values from the global configuration file, normally /etc/gnupg/gpgconf.conf, and updates user configuration files. This is a legacy mechanism; modern applications should use the per-component global configuration files under /etc/gnupg/ instead.

Inspect the file as root, without applying it:

# ls -l /etc/gnupg/gpgconf.conf
# gpgconf --check-config /etc/gnupg/gpgconf.conf
# gpgconf --list-config /etc/gnupg/gpgconf.conf

A successful syntax check normally produces no output and returns status 0. The listing is colon-separated data, so do not edit it as if it were a shell script. If the file is absent, empty or not the file your change process approved, stop here. The apply command is not a dry run and has no preview mode documented by its manual.

Do not combine gpgconf.conf with modern per-component global files without a deliberate migration plan. The local gpgconf manual says using both is not suggested, and two policy mechanisms make it harder to explain a user's final configuration.

3. Record the users and homes in scope

The wrapper's scope is narrower than "every account". It targets real users with an existing GnuPG home directory. Accounts without one are not made into GnuPG users by this command.

Before changing anything, make a change record containing the policy file checksum, the maintenance time and the accounts you expect to be affected:

# sha256sum /etc/gnupg/gpgconf.conf
# getent passwd | awk -F: '$3 >= 1000 && $7 !~ /(nologin|false)$/ {print $1}'
# find /home -maxdepth 2 -type d -name .gnupg -print

The account query is only a review aid, not the wrapper's authoritative user-selection algorithm. User homes may live outside /home, and a numeric UID range is site-specific. Check your directory service, home layout and backups before relying on the list.

4. Protect the current configuration before applying

Applying defaults can change files in users' GnuPG homes. Make a recoverable backup of each affected .gnupg directory using your normal backup tooling, and record its location. This is the safety boundary: do not proceed if you cannot restore the previous configuration.

Do not copy private keys into a shared or world-readable backup location. Preserve ownership and permissions, and restrict access to the administrators authorised to handle those homes. If your backup process cannot preserve those properties, use a tested system backup instead of improvising a tar archive.

There is no universal undo command in applygnupgdefaults. Recovery means restoring the affected configuration files from your backup, with their original owner and mode, then checking the relevant GnuPG component. Keep the policy file too, because the next application will reproduce its values.

5. Apply the defaults during the maintenance window

Only root should invoke the wrapper, because it must act on other users' homes:

# /usr/sbin/applygnupgdefaults
# printf 'applygnupgdefaults status: %s\n' "$?"
applygnupgdefaults status: 0

The command has no documented options or per-user argument in its synopsis. Do not append a username expecting to limit the run. A zero status means the wrapper completed successfully; it does not mean that every account had a home, every intended option was accepted, or that a user cannot later edit a file.

GnuPG configuration changes can affect agents, clients and automation. Avoid running this while users are actively changing their GnuPG settings. The gpgconf manual warns that concurrent access is not fully locked, so coordinate with jobs that may write the same files.

6. Verify the result without assuming enforcement

Recheck the policy syntax and inspect representative user configuration after the run:

# gpgconf --check-config /etc/gnupg/gpgconf.conf
# stat -c '%U %a %n' /home/EXAMPLE_USER/.gnupg/*
# grep -n '^' /home/EXAMPLE_USER/.gnupg/CONFIG_FILE

Replace EXAMPLE_USER and CONFIG_FILE with a real account and a configuration file covered by the approved policy. Check more than one home when the host has different account types or home locations. Confirm that ownership and modes remain appropriate, and ask the application owner to test the affected GnuPG operation.

This wrapper is not a bulletproof enforcement mechanism. A user can directly edit the generated configuration and bypass the defaults. If a setting must be enforced against deliberate changes, use a policy design that provides that guarantee and document its operational impact. Do not claim enforcement merely because this command returned 0.

Common traps

• Running as an ordinary user: the manual specifies invocation by root. A user-level run cannot apply policy to all relevant homes.
• Expecting new homes: only real users with an existing GnuPG home are in scope.
• Using a preview that does not exist: the wrapper has no documented dry-run option. Inspect and back up first.
• Editing the wrong policy: /etc/gnupg/gpgconf.conf is the usual legacy file, but verify the installed gpgconf behaviour and your deployment.
• Overclaiming the result: a generated setting can be changed by the user and is not a permanent security boundary.